7 Principles of Testing - Part 2

In our first article we talked about the first and second principle of software testing - Testing shows presence of defects and exhaustive testing is impossible. We will now talk about principle three and four.

Principle 3. Early testing

Testing activities should start as early as possible in the software or system development life cycle and should be focused on defined objectives.
This principle is connected with the notion of “cost of defect”. The cost of defects rises considerably across the life cycle. The earlier we find a defect, the quicker, easier, and cheaper it would be to fix the defect.

If a defect is detected in the requirements, then it is the cheapest to fix. If the defect is detected at the design stage then the design can be relatively easily corrected. If however a defect is introduced in the requirement specification and it is not detected until system or acceptance testing then it will be much more expensive to fix. This is because rework will be needed in the specification and design before changes can be made in construction. Besides, one defect in the requirements may well propagate into several places in the design and code, and after implementing the required changes all the testing work will need to be repeated. It is quite often the case that defects detected at a very late stage are not corrected at all because the cost of doing so is too high.

Also, if the software is delivered and formally meets an agreed specification, but it is not what the users wanted this can lead to users being unhappy with the new system, as well as difficulties in selling and implementing the system, etc. It means that the requirements were incomplete, but the error has not been detected.

That is why it is so important to start testing as early as possible, using static techniques.

Early testing

Another important advantage of early testing is that it saves time. You may start your testing activities before the first code line is written. While requirements and specifications are being prepared, the tester can start developing and reviewing test cases. And once the first test version is ready, they may go to test execution.

Principle 4. Defect clustering

A small number of modules contain most of the defects discovered during pre-release testing or show the most operational failures.

One phenomenon that many testers have observed is that defects tend to cluster. This can happen because an area of the code is particularly complex and tricky, or because changing software and other products tends to cause knock-on defects. Testers will often use this information when making their risk assessment for planning the tests, and will focus on known 'hot spots'.

Defect clusters can be identified at early stages while carrying out static testing (e.g. code review or code analysis with special tools). When it comes to the point of dynamic testing, you may focus on the areas where you have found more defects with static techniques.

We might also carry out root cause analysis to prevent defects and failures happening again and perhaps to identify the cause of clusters and potential future clusters.

We will address the last of the principle in a future article.

Victoria Slinyavchuk
Consultant on Software Testing