Let us formulate the basic principles of testing using the premise that psychology plays the most important role in testing software applications. These principles are worth attention because they are mostly intuitively clear, but at the same time they are often not given due attention.
| A description of the expected values of the output data or results should be an integral part of the test suite. |
Violation of this obvious principle is one of the most common mistakes. Erroneous but plausible results can be considered correct if the results of the test were not pre-determined. Here we come across psychological phenomenon: we see what we want to see. In other words, despite the fact that testing by definition is a destructive process, there is a subconscious desire to see the correct result. One way to deal with this is to encourage a detailed analysis of the output variables in advance, when developing the test. Therefore, the test should include two components: a description of the input data and a description of the exact and correct results corresponding to the set of input data.
The need for this was emphasized by logic of Irving Marmer Copi, a famous philosopher: “The problem can be characterized as a fact or a group of facts that do not have an acceptable explanation that seem unusual or that cannot be fitted to our perceptions or assumptions. It is obvious that if something is questioned, then some preliminary information should be provided about it. If there are no assumptions, then there can be no unexpected results.”
You know, penetration testing services providers strive to remove security weaknesses by safely exploiting them to understand how a potential attacker may break the system.
| No program should be tested by its author. |
Unfortunately, the implementation of this generally sound principle is not always possible due to three factors:
1) human development resources are generally inadequate;
2) regular application of this principle to each program requires a very high qualification of all programmers or a large group of programmers who test all programs, which is not always feasible;
3) a high level of formalization of the development process; detailed formalized requirements specifications for programs and data, a thorough description of the interface and formalization of responsibility for product quality.
