Software Testing – From What Should We start?

Software Testing – From What Should We start?
April 19 10:00 2011 Print This Article

I have always been wondered what a software testing is. Why are we need to hire someone to test a software product, if the developer can spend a couple of hours on this is not a significant priority for the job. And, finally, why do I test? After all, programmers are smart guys – they write correctly. But it is not so easy as I thought.

Software Testing - From What Should We start?

Not having any idea of ​​what and how it should be given “to the input of” application under testing so process seemed endless. As a result a vicious circle in which the torn dates of testing, everybody is angry and tired of “stupid” developers.

And only much later I singled out for themselves a clear sequence of actions that must be performed to software testing:

1. The study of the specification. This stage is the most important; it is also called the analysis of design and / or requirements.
2. Smoke testing. At this stage, we must verify whether the system works in general (whether it works properly, “complains” when not working out right, etc.). This is done in order to understand whether the application is suitable for further testing, or it does not work (does not work correctly).
3. “Positive” test. At this stage, we must verify the result of the application upon receipt of “correct” input.
4. “Negative” test. This is the fourth and final stage of initial testing. You’ve got to look at the behavior of the application, getting the input of the “wrong” data. This is done in order to determine how the application behaves in such a case. If this option is described in the specification, and it should be described, then compare the expected result with the obtained result.

So let’s go in order.

Specification, Requirements, SRS.

How to determine when and how the application should work, when, and how it should “break” (i.e., as a system or module should respond to invalid data or incorrect behavior of the user)? How should be the correct result and under what conditions the input data working correctly should take place?

All these questions have an answer in the documentation for the application under test. In any case,  the answer should be there, otherwise the documentation is not complete, which equates to an error in the documentation.

Documentation makes it possible to understand for themselves the basic steps of checking the application, where and how the application should work and where it should “break”.

The testing process

This process can be described by the following steps:

1. Check how the application works when it gets to the input of the “correct” data (to find out “what is good and what is bad,” read the documentation);
2. If everything works and works properly (i.e., exactly as described in the specification), the next step is to check the boundary values ​​(i.e., where the “correct” data start, and where they end);
3. To test the application during data entry that are not within the scope of permissible values ​​(again, consider the specification).

The first and second paragraphs describe a process called “positive” test. “Positive” test is a test on the data or scenarios that correspond to the normal (regular, expected) behavior of the system under test.

The third item represents the opposite of “positive” process – a “negative” test. This testing data or scenarios that correspond to the abnormal behavior of the system being tested – various messages of software bugs, exceptions, “outrageous” states, etc.

However, preceded by “positive” and “negative” test should be work to implement the “smoke” testing.
“Smoke” testing is a fast, shallow, the most common or typical scenarios, with a minimum of checks (just it was no smoke). It can run as on “positive” and “negative” data.

Related Posts:

  • No Related Posts

About Article Author

view more articles
Nataliia Vasylyna

View More Articles
  • Aleksander Lipski

    “All these questions have an answer in the documentation for the application under test. In any case, the answer should be there, otherwise the documentation is not complete, which equates to an error in the documentation.”

    Do you really think that documentation can have all answers for such questions ? It is not possible to describe every behavior of the product with all details in documentation. That’s why testing is more then just verifying product with existing documentation

    Alek