The main principles of testing are also the foundation of the ISTQB syllabus. In the following post, I would present knowledge in a short concise form of a „test injection”.
Testing reveals defects, but cannot prove they didn’t exist
Sure. Any detailed verification of the problems doesn’t prove that you can’t find more of them in the App – it’s always just a matter of time and budget for testing.
Here, I will bring up one more issue to this point – asking another Tester to test what we tested ourselves in case of doubt, an additional pair of eyes will definitely pick up seemingly invisible errors even more accurately.
Thorough testing is not possible
The indication that the artificial rebuilding of the application can’t be tested (all functionalities), except for very simple applications.
Early testing saves time and money
First of all, when we found a defect at an early stage of work, it is much easier and cheaper to fix it.
Accumulation of defects
The principle of accumulation of errors is that if we are aware of where the occurrence of many cases in the application is, we have the ability to predict where the greater test risk and which modules need to be more detailed tested.
The pesticide paradox
What is this rule about? This paradox applies to the situation when we always test the same scenarios on the application. This leads to a situation where we stop testing errors in time. It used to be mistaken that the application has no defects.
The mistake is assuming no errors
Briefly and succinctly – you have to assume that the application always contains some bugs or issues. Sometimes in more difficult IT projects, some numbers of minor defects are acceptable.
The above content is just a schema, the rules are timeless and it is worth having them „behind the head” during tests of a simple application as well as a complex system