Psychology of testing (of course, not exhaustive). Personal translation from the book “The Art of Testing” by G. Myers

An important reason for the poor testing of software products is that most experts are repelled by the false definition of this term. They may say:

- testing is a process for demonstrating that there are no errors in the program;
- the purpose of testing is to show that the program performs the expected actions from it correctly;
- Testing is a process aimed at creating confidence that the program is doing what it should.

These definitions are incorrect.

Here you have a deductive reasoning:
')
While fitting into testing, we wish to add value (value) to a product -
Adding value to the product occurs by increasing the quality and reliability of the product -
Adding product reliability occurs by searching and removing errors.

Therefore, do not test. Do not test to show that everything works; Start with the axiom - the program contains errors (by the way, this is true for most programs), and then test it to find them as many as possible, as if this is your last day (in testing).

But the definition is better:

Testing is the process of working with a program with a persistent intention to find errors. And although it may sound like a certain game of subtle semantic matters, there is a really important component here. Understanding the true definition of the testing process can have a profound effect on success in your endeavors.

Humans are creatures for whom an orientation toward certain goals is important, and the installation of such has an important psychological significance. If our goal is to show that the product has no errors, we will unknowingly strive for that goal; hence, our actions will be such that will reduce the likelihood of failures. On the other hand (did I translate correctly? - note of me), if your goal is to demonstrate that the program contains errors, your tests will be more successful in finding the latter. This approach will add more value to the product than the previous one.

This definition includes many aspects. For example, it implies some kind of destructive, sadistic nature of testing. What can contradict our life views: after all, most of us like to create more than destroy. Most people tend to create objects, but not to destroy them. This definition also includes an installation for test design and an installation for who should test and who should not.

Another way to grasp the definition of testing is properly the analysis of the use of the words “successful” and “unsuccessful” - in particular, their application to the results of passing the test cases. Most managers perceive tests that have not identified errors as “successfully completed,” and those that detect errors are usually called “unsuccessful."

And again this is a changeling. “Unsuccessful” means something unwanted or disappointing. According to our view, a well-designed test, well executed, is successful if it helps to find a bug that can be fixed. The same test we also call successful, if in the end it reports that there are no errors that can be found. The only case where the test can be called unsuccessful is if it cannot properly investigate the System. And in most cases this is probably the case, since the concept of software without errors is fundamentally unrealistic.

How can you call a test that found a new error, unsuccessful? After all, he provided an investment in the value of the product. But a test that executes a program with correct results without errors found can be called unsuccessful.

Consider the analogy with a visit to the doctor due to general malaise. If the doctor starts doing any laboratory tests that do not detect the problem, we will not call them successful; they are unsuccessful because the patient’s wallet is empty and he is still sick. There are questions about the qualifications of the doctor. Conversely, tests are successful if they have diagnosed an ulcer, and the doctor can begin treatment. It seems that in the medical profession these words are used in the right way. The analogy is that we should take a software product as if it were a sick patient.

Another problem with the definition of testing as "the process of demonstrating that there are no errors in the program" is that this goal is unattainable for almost all, even unpretentious programs.

We repeat, the results of psychological studies say that a person is ineffective when his installation on solving a problem contains preconditions of inexpediency or impossibility. For example, if you have a task to solve a complex puzzle in 15 minutes, your success in ten minutes will be small, because you, if you are like most people, will soon conclude that it is impossible to complete the task. If a solution is needed within four hours, we can expect more success in the first ten minutes. If we consider the testing process as a process of identifying the presence of errors, this is a feasible task that allows you to cope with this psychological problem.

The problem with defining testing as “the process of demonstrating that a program does what it should do” is that the program that fulfills this condition still contains errors. In other words, there is an error in a program that does not do what it should - this is obvious. But errors are present in the program, which does what it should not do. We are likely to do better by viewing the testing process as a process of searching for errors, rather than as a process whose goal is to show that the program does what it should.

Concluding, it is correct to consider software testing as a destructive process, consisting of attempts to find errors that are expected to be present. Luck is to bring the application to failure, and the "blue screen of death" - the highest point. Yes, we want to achieve during the installation testing a certain degree of confidence that the program does what it was created for and does not do anything else. Mistakes can be an excellent guide to this goal.

Imagine that someone claims that his program is perfect, that is, does not contain errors. The best way to verify the truth of this statement is to try to disprove it. In other words, you should try to find flaws with a greater desire, rather than agree that the program works correctly for a particular data set.