There are seven notes in music, seven basic colors, 7 continents in the world, 7 colors in the rainbow. There are seven main principles in software testing, too. These rules should be on your desk or at least in a corner of your mind. Let’s talk about these now:
1. Testing shows the presence of defects, not their absence
By testing, we can get the best possible form of a product. We can minimize the loss of money/time/status, but we cannot always say that this product is 100% defect-free. No matter how many times we test it, let’s solve all the bugs we reach, but there are always tests that aren’t run somewhere. It could be healthier for us to move forward when idea of achieve 100% of the needs, not the idea of find 100% of mistakes.
2. Exhaustive Testing is Not Possible
There is no possible way to test all possibilities. Testing all the scenarios we can create is not possible in terms of budget and time and also very difficult for our psychology! Therefore, it will be the most logical option for us to determine our risks and priorities and to run a reasonable number of tests. A testing organization with the right feasibility will be close to testing unlimited options and we can expect this to be as bug-free as possible.
3. Most of the defects cluster in the same place.
That’s right, Pareto again! The 80-20 ratio is seen here. Maybe in certain modules or certain people in the team. Understanding this is somewhat experiential, but navigating around the errors we find can make things easier.
4. Testing at an early stage saves Time and Money
In classical processes, testing seems to be an activity that takes place towards the end of the project, but testing activities must start from the earliest stages of the Software Development Life Cycle (SDLC). Tests should be carried out at every stage of the project. As soon as the project starts, all requirement documents and related documents should be reviewed according to the business requirement. In this way, untestable, uncertain and unmeasurable requirements can be determined from the beginning. Defects detected at an early stage cause less time/money loss.
5. A pesticide (antibiotic effect) paradox
If we say that bugs gain resistance to the same poisons … But how can the software product be immune to testing? It is like this; If the same tests are repeated every time the errors in the software are corrected, you can see that the same errors do not repeat. The same case, the same data and the same tester will greatly strengthen this immunity. However, after the changes to be made, other bugs may occur.
6. Testing is context dependent
While the main concept is the same, the testing approach varies by context/project. Different sectors have different needs. Energy sector, Telecom sector, Banking sector etc. They all have different priorities and risks. For this reason, it is useful to consider the dynamics of the industry while creating a test strategy.
7. Absence of errors fallacy
This principle is very parallel to our first principle. It would be wrong to say that something that we cannot test 100% is completely error-free. We should not overlook the difference between not being able to find a mistake and having no possibility of making a mistake. Regardless of experience, anyone can make mistakes. Additionally, expecting the test team to be completely error-free, can lead to social and technical conflicts between teams.