It is noticed that some people turn out to be very good at testing their own programs. They have the ability to find errors even without using any testing methodology (such as boundary value analysis or function diagrams).
This is explained by the fact that a person with practical experience often subconsciously applies the test design method called the error guessing. Using a specific program, the man intuitively guesses probable types of errors and then develops tests to detect them.
The error guessing method is difficult to describe, since it is largely intuitive. Its main idea is to list possible errors or situations in which they can appear, and then write tests on the basis of this list. For example, this situation occurs when the value 0 is at the input and output of the program. Therefore, it is possible to construct tests for which certain input data have zero values and for which certain output data have zero values too. For a variable number of inputs or outputs (for example, the number of input records that are searched for in the list) errors are possible in situations such as “none” and “one” (for example, an empty list, a list containing only one record). Another idea is to define tests related to the assumptions that the programmer can make while reading the specification (i.e., the points that were omitted from the specification either accidentally or because the author of the specification considered them obvious).
Do not forget using pen testing service otherwise your sensitive data will be known to hackers! Protect security of your IT infrastructure with the help of experienced pen testers from Ukraine!
Since this procedure cannot be clearly defined, the best way to discuss the meaning of the error guessing is to parse examples. If you consider the testing of a sorting subroutine as an example, you need to investigate the following situations:
The list to be sorted is empty.
The list to be sorted contains only one value.
All entries in the sorted list have the same value.
The list is already sorted.
In other words, it is required to list those special cases that may not be taken into account when designing the program. If the example is testing a binary search subroutine, you can check the following situations:
1) There is only one input to the table in which the search is performed.
2) The table size is a power of two (for example, 16).
3) The table size is less or more than power of two (for example, 15, 17).
Comments are closed.
