As much as the quality triangle is a crucial first component of building quality software – that definition and understanding of what quality needs to go beyond some of the traditionally held views of just testing it. While many companies would admit that software quality is a team effort, most place the responsibility on the QA and testing team, with the hope that they will simply find all the defects and that will lead to mostly defect-free software. This is an antiquated view though and needs to drastically change.
The idea of software quality has transcended the expertise of software testing, with which it is often so closely associated. And rather moved towards a combination of all software development efforts and the synergy in which they are integrated to work together. Quality cannot be assured through testing alone but through deliberate planning and effort. By doing this, the software can be built right, reducing the impact on testing and likely reducing most defects before a tester has even started to perform their own testing.
Quality is also not just judged by how defect-free the software appears to be, but also through its maintainability, secureness, the efficiency of use, and the ability for teams to work together to build and maintain it with as little waste as possible. It’s about meeting the needs of its users, without creating unnecessary bottlenecks of manpower and process along the way. It’s maximizing the potential of software to deliver its purpose as profitability and cost-effectively as possible.
Yes, quality is at the center of the software development process and indeed the companies who use it. Quality is something that you will read about in many companies' promises around how good their software is. And yet, somehow few actually understand what developing quality software actually means. And sadly, fewer testers do as well, as they focus on the aspect of finding defects in the software rather than looking at it holistically.
The truth is though that designing software of high quality has little to actually do with testing or more to do with intelligent design. If you want to make high-quality software, it is the process of deliberate design of the software and less the excellence of the software testing conducted. This is not to mitigate the science of testing which remains an integral part of the process, but rather is just to highlight how important all prospects of software architecture, design, analysis, process, and, yes, testing, are required to work together to make software of high quality.
None of this is possible by just focusing on one aspect of software development but on the whole. And by making a deliberate effort as testers to work with the rest of the engineering team to align all of these together to allow for better quality. Quality is the outcome of proper software engineering principles and a deliberate effort. Yes, aspects of quality can be achieved through elements of these software engineering principles but are unlikely to be long-lasting or achieve maximum effectiveness without all these aspects coming together.
Quality is a team effort, and any team needs all members coming together to make it work. As a tester, it’s your role to try and bring everyone together and play a part in making quality central to all of your planning efforts.
Don’t Break Stuff
However, I do think part of this blame can be on testers who take pride in wanting to break stuff and find bigs, rather than look for ways to prevent defects from happening in the first place.
A common phrase I have heard from many software testers, either in interviews or when asked why they enjoy their jobs in testing, is how they enjoy breaking stuff. And while I admit there is a certain satisfaction in finding those gaps in design and development and discovering these defects before they go into production, the truth is that testing is not meant to break things.
Good testing should lead to defect prevention rather than defect discovery. When defects are found, we should focus on finding ways to improve the software and build it better to prevent those issues from occurring again. These issues typically lead to better planning efforts and working with your team to rather design software differently so that issues are prevented over time.
So, as testers, while we should continue to find methods of testing the limits of our software and find defects before they make it to production, we shouldn’t pride ourselves in how many defects we can find and rather pride ourselves in how we worked with our teams to not find those sorts of defects in the future.