Since 1957, testing was just a process to find out to is software working as expected. It was just a simple debugging and error checking without its special identity. Usually made by a programmer who developed software.
After a while, software testing evolved into its own segment in the software development cycle. With this evolution, 7 principles arose, which became the common practices across testing teams in the world. In this article, we will evaluate each of them.
1. Exhaustive testing is not possible
2. Defect clustering
3. Pesticide paradox
4. Testing shows the presence of defects
5. Absence of errors fallacy
6. Early testing
7. Testing is context-dependent
These 7 rules are the holy grail of testing. How you will use them depends on you. You can apply them strictly to your work or ignore them.
One fun fact is that you will use them without being aware, and might only realize that after only some time. Even if you are not familiar with the above, we will describe them from tester’s point of view and define them along with giving you more details. Let’s look closely at each.
Yes, it is not possible and usually testing revolves around confidence and its levels. It’s about how confident we can be something works.
The more we tested, the higher confidence level should be achieved. Sometimes, we may be overtesting. This brings nonefficiency. While not entirely an issue in big teams, it is a great obstacle in smaller teams, which cannot afford the luxury of wastefulness.
What we need in that case is a well-constructed and considered coverage of an application based on the risk assessments. Having a good plan for testing is the biggest time saver. Without it, we may be going in circles and spending too much time testing one aspect when others are left to be.
This rule shows that most of the bugs are coming from other bugs or have the same root cause as the other ones.
What is worth mentioning is that those are usually the small things. Experienced software developers or testers are usually prepared for this. They also know that there are certain areas that are generating more bugs than others. For example, an area that is often to blame is handling the back button in Flutter.
What is important is that you shouldn’t fall into a routine and test the same modules repeatedly.
This one is simple. Using the same testing technic repeatedly will not bring any new results. You may use the same pesticide over and over, but it won't remove the pests, that remained after previous usages. Paradoxically, the number of pests may even increase!
How to avoid Pesticide Paradox? Use your team and switch tasks with your colleagues. Sometimes others will notice something you didn’t. After all, two heads are better than one. Focus on various areas of the project.
As a side note, this paradox is a very well documented one, and you may found the abundance of information on it, and even mathematical formulas.
Testing is the best strategy to get bug-free software.
Without testing, you can't possibly feel confident about releases, and you won’t know the real behavior of your application. The bugs that you uncover would have shown up sooner or later. This principle could be connected to the fallacy of blaming the person for delivering bad news. The idiom “don’t shoot the messenger” is there for a reason!
We will reiterate: being fully confident about your software is impossible. Tests will simply show if you are on the good path to achieving the expected results that your client requested.
Even if your tests show that your software is bug-free, it’s most likely not the case.
Sometimes you could just identify your client's needs incorrectly or the requirements will be changed once you were on your leave. This is just an example of how swiftly projects can change and with the changes, those errors can be generated. Though overly pessimistic, software engineers ought to always assume the worst and try to do their best regardless of circumstances.
Then again, some bugs like to hide, and some are quite enigmatic. Even the best software teams will produce defects, and the only thing we can do is to strive to do better. Whether perfection is possible or not, writing good software is like making fine porcelain: it will always be appreciated.
Just as the early bird gets the worm, the early bird is more confident in its software. The earlier we will test out things, the more time we will get for certain actions. So once the client defines the requirements and describes the intended behavior, we can test the theory against the expected results. The faster we test everything, the smaller amount of work we will need to put in defects to fix them down the line, and it should lower the overall costs.
This is a quintessential rule.
Not all testing approaches work in each project. Some will work in one environment, while others in other environments.
Use different approaches, different techniques and try to be creative about them as each type of software differs from another. Sometimes you will have to learn odd rules, but each lesson comes with a profit at the end. The lessons you might frown at one day could become invaluable at any stage of your career.
To summarize, those 7 rules can improve your testing or understanding of software development.
What we observe is that once you gain some experience in the area of software development, you will use the aforementioned even without thinking of them. For the ones who just begin their journeys, they are all a great cheat sheet to have, in addition to other good practice that you should introduce to your work when mastering software engineering.
Finally, we must ask you: would you say the rules above are helpful? Maybe one of them is a mistake? Did you know them or even used on the daily basis? If yes, then you can get in touch with us and share your thoughts with us. Maybe you are looking for some specialists who apply those in their work? Feel free to contact us, and we will see how we can deliver value to your company.
.svg){kind=small}
