Does the tester need the guide for all testing?
Yes, and the 7 testing principles offer those guidelines.
Let’s dig into these principles and talk about them.
1. Testing shows the presence, not their absence.
But what does it mean exactly?
That means, we can discover a lot of bugs in the tested software, but we cannot prove that there are no defects. Even if we won’t find any defects in tested software, we cannot tell, the software is correct absolutely.
Testing has a negative psychological character because some people can perceive it’s a destructive activity, but that’s not true.
Testing contributes greatly to project progress and product quality.
2. Exhaustive testing is not possible.
We can decide to test every input and precondition of our software, its every element, everything, but it’s not possible. We have not enough time to do it.
Only in trivial cases, exhaustive testing is possible. Instead of that, we can use risk analysis, test techniques, and test prioritization.
Let’s see the example.
Tester (let’s say his name is X), so X is testing the big software.
He got the month for doing all test activities and delivering the summary report.
He starts to test all the elements of the software, all inputs, and preconditions, but after this month of testing, he is annoyed because the summary report is still not ready and some elements of the software are not tested yet.
The test manager is angry because he has not the summary report, which can mean a lack of information about defects as well, as a result, he can’t know if the whole software is tested and bug-free.
What could to do for our tester instead of that?
He could use the risk analysis and test prioritize to test the most elements of software and prepare the summarise report for a manager, who would have the information about the risk and defects on the time, which could be helpful to release the software faster.
As we can see from this example, it’s important to use the risk analysis and prioritize the testing activities to deliver software on the time and test the most elements and inputs of the software.
3. Early testing can save time and money.
We need to test our software (we can use both static and dynamic test techniques) as early as possible to find defects early and fix them early.
It’s referred also to as a shift left.
As far as we won’t find defects, its cost is growing up on every software development lifecycle level.
Let’s imagine the situation.
Our tester X is starting to test the software after the programmer wrote the application code, and he finds a lot of defects. It happens just before deploying the software to production.
What is the cost of fixing the bugs?
It’s a huge cost because the software needs to be fixed before the deployment, and hence the software release is delayed, and as a result, the company has more money loss.
What would happen if X tests the software before the code has been written?
The company would save more money and the software would be released at the correct time.
We need to remember the shift left principle is really important in software testing because it saves a lot of time and money.
4. Defects cluster together.
This principle means that a small number of modules contains the most defects.
As the Pareto principle tells, in 20% of the module, 80% of defects are detected.
For example, we can test the software, which we are divided into modules: A, B, C, D. We’ve tested all of the modules, but in module C we saw more defects than in others. In that case, we should focus on module C and conduct more test activities on it to look for more defects.
As we can see, this principle should be done in the software testing process to help the defects detection and fixation.
5. Beware of the pesticide paradox.
Well, here we have the principle, which warns us to not repeat the same tests because these tests won’t be effective to find new defects. Only the test checking and updating can help to find the new defects, otherwise, these tests will be useless.
Ok, let’s look at this story.
Our X has 5 years of testing commercial experience in one company. He wrote the tests when he started work in this company and never updated that. His tests stopped finding the new defects, which made them useless.
What if X would check and update his tests?
It could be much better because his test would be more powerful and would find more defects.
We ought to remember to always check the tests and update them if is necessary to make them the most powerful to find new defects.
6. Testing is context depend.
Testing can be done differently in different contexts.
For example, we will test the game in another way as the web banking application.
The test process needs to be different in these applications because have the other elements and inputs to test.
7. Absence-of-errors is a fallacy.
Some organizations require that testers will provide them with bug-free software, but as principles 2 and 1 show, it’s not possible.
Let’s analyze that story as an example.
Tester X provides bug-free software. This software is deployed to production. Users start using this software but they are not satisfied.
Why?
Because the software can be bug-free, but it needs to be validated as well that it fulfills the user’s expectations.
As we may see, the 7 testing principles are really useful to help testers better test.
I hope you enjoyed the reading and saw something interesting in this article.
The next post will arrive soon 🙂
The part content of this post was based on ISTQB FL Syllabus (v. 2018).
Graphics with hyperlinks used in this post have a different source, the full URL included in hyperlinks.
