Software Quality is one of the most important considerations for organisations working in the modern, digitally transforming world – especially the world learning to live with a ‘new normal’ of workplace dynamics and social interactions.

But the term itself – software quality – is rather vague. On its own, it doesn’t really define a standard that organisations can follow to test and optimise their software and systems. That said, the International Organization for Standardization (ISO) has identified seven key principles of Software Testing that can be applied to achieve optimal quality, which have now been adopted by the International Software Testing Qualifications Board (ISTQB).

The principles are as follows (though not always in the same order):

• Exhaustive Testing is not possible. That’s right, we can’t test everything. The best way to do it is to first assess where the highest risks exist in the software or system, and narrow your testing to those risks.
   
• Defect clustering. There’s a general rule that says the highest number of defects can be found in the smallest number of parts (or clusters) in the software or system. Limit your test cases to these clusters, but keep a mindful eye on the rest of the system.
   
• The pesticide paradox. The same way that using the same pesticide to eradicate pests on crop fields makes the pesticides more resistant over time, so using the same tests to determine software quality will make them less effective over time.
   
• Testing shows the presence of defects. We don’t test for the absence of defects, but rather their presence. That means we can’t be 100% sure there are no defects, or that the software works well despite the presence of defects.
   
• The absence of error fallacy. Following on from the previous principle, even if software is 99% defect-free doesn’t mean it’s usable. That’s because software testing isn’t limited to finding defects, but also testing for suitability to the business case.
   
• Early Testing. Testing should always be done as early in the Software Design Lifecycle (SDLC) as possible, so that defects don’t carry through to latter stages of software development, where they become more difficult and costly to fix.
   
• Testing is context dependent. Testing varies by application, by business case and even by client type. The way you test a website is different to how you’d test an e-commerce platform or ERP system. This goes for everything from testing type to methodology, not just test cases.

About Sastri

Sastri is a passionate and engaging mentor, educator and speaker with extensive experience of real-world testing and automation projects. He has worked in the consultancy industry for over 17 years. He has implemented test automation on various systems ranging from desktop, Web, SAP and mobile applications in multiple industries across the world, with an emphasis on defining an efficient and profitable automation strategy. As a mentor, Munsamy has hosted testing community meetups in Cape Town and Johannesburg, and has guest spoken at numerous industry events.