Determination of the scope of testing
When determining the testing scope and testing coverage, it is important to consider which part of the software product should be tested. It has long been established in the software testing field that a program which implements most of the functionality cannot be fully tested. Is it possible to perform an exhaustive testing of the program? The answer will always be no, never. Of course, you can perform a fairly thorough testing of the good old program that produces the phrase “hello, world”, which contains only a few lines, has no conditional state transitions, a GUI-interface (Graphical User Interface). Nevertheless, for the programs that implement real-world tasks, it is common to determine a certain level specificity of given input, some combinations of input sequences or code branches and all this cannot be verified because of time constraints.
Web application testing service is useful for people to examine and test end-to-end organizational processes across an enterprise software app.
Is it possible to test a program exhaustively?
The first thing you need to do before you start designing tests is to define the total scope of test effort. Is it necessary to attempt to perform exhaustive testing of the software, or do there exist fundamental limitations as to what can be expected from the testing activity?
There are two types of input: valid and invalid. Five-digit positive integers are valid input, while negative integers, numbers with a decimal point, letters of the alphabet, control codes and spaces are not considered as valid input.
For example, a simple calculation of the number of valid zip codes indicates that the number of valid entries is 100,000 (five-digit numbers not allowed by the postal service are ignored). Suppose that automation is not used in this case, i.e. the program is tested in a manual manner. The testing procedure requires the tester to manually enter valid input values, send requests to the database to obtain the cost of shipping, compare the calculated values of the shipping cost and record the results. You can easily spend 3 minutes per input, so 5000 hours will be spent checking all valid input values, which is more than 2 years of hard work. In addition, such verification may have to be performed several times, since each new version should be tested in a completely similar way.
In fact, it is simply impossible to check all possible input values. The picture changes if you automate the testing activity under consideration, but even in this case you will hardly want to waste time automating and testing every possible input.
Add Comment