The 7 Essential Principles of Software Testing

In the world of software testing, just like in the world of art, those of us who are motivated by excellence are eager to fill our box of crayons with as many and as varied colors as possible. Naturally, primary colors cannot be missing, as they are the basic tools of our kit. The ones that due to their relevance are completely essential. Those that simply have to be present in every box of crayons, no matter how newbie we may be.

In our work as software testers, our box of crayons is made up of a set of skills and knowledge that allows us to perform daily in every project that has been assigned to us. Each bit of knowledge, whether it is a method, technique or skill, for example, would represent a color, that is, an element that will add value to our profession and make us more efficient.

Beyond each of the methods that will undoubtedly enrich our skills and performance to a great extent, allowing us to design test cases, run exploratory tests, perform automated tests and much more, it is indispensable to have a collection of essential principles that will prove to be very useful in our commitment to carry out our work with seriousness and dedication.

It is important to note that the principles listed here did not emerge from my own observations or personal opinions, but are rather the result of extensive research.

These are the 7 Essential Principles of Software Testing that cannot be missing in our collection:

1. Testing shows the presence of defects

Testing allows us to demonstrate the existence of incidents in a product, not their absence. After an incident is reported and subsequently repaired, it is possible to reduce the probability that incidents not yet discovered will persist in the system, but the absolute absence of incidents is not only impossible to verify, it is also an extremely unlikely possibility.

1. Exhaustive testing is not possible

Except for specific cases, testing every possible combination of data and actions in all the functionalities of a software is generally not a viable option, either for reasons related to time, costs or resources. For this reason, when structuring our strategies and designing test cases, it is very convenient to consider these factors, so that we focus on executing the most significant verifications that, besides, also have the greatest impact.

1. Early testing

When the testing process begins in the earliest stages of software development, this alliance is extremely beneficial, as it allows incidents to be detected in the dawn of product blossoming. The cost of repairing these incidents would be significantly higher if they were only detected in later phases.

1. Defect Clustering

Generally, there are certain modules and functionalities that are more likely to conceal incidents (of higher priority) when compared to the rest of the parts of a product. This principle is related to the 80/20 Rule, which states that approximately 80% of the consequences emerge from 20% of the causes. In more precise terms, this could be translated as follows: not all software components have the same level of relevance, so the most favorable approach when developing our testing strategy is to concentrate our efforts precisely on the most crucial parts, to detect those incidents that may need to be solved more urgently than the rest.

1. Pesticide paradox

Running the same tests on the same stable part of a system repeatedly is a practice that tends to hinder the detection of new incidents that have not yet been detected. Therefore, to increase the chances of detecting incidents, it is important that we constantly review and update our testing strategy and ensure that we explore the various parts that make up the product at a deeper level.

1. Testing is context-dependent

The strategy and type of tests we choose to perform will be selected depending on the system and the environments that we want to verify. For example, medical software will not be tested in the same way as an e-commerce system. The procedures we use, as well as the cases we design, will be selected taking into consideration each and every one of these factors.

1. Absence of errors fallacy

Suppose that all the incidents detected in a given system are now fixed. Next, a new test cycle is carried out, after which the presence of new incidents is not detected. The absence of new errors detected does not imply, however, that the software is useful. Its usefulness is not indicated by this parameter, but rather by the satisfaction of the customer’s expectations that such a product can provide.

Knowing and applying these principles helps us organize our testing strategy in an innovative way, and provides us a privileged view, which in turn will allow us to work with more accuracy and efficiency.

We hope that these fundamentals prove to be very useful to you. We’d love to hear your experiences after adding these colors to your box of crayons!

Follow us on Linkedin, Facebook, Twitter, and Instagram to be part of our community!