At the heart of software quality, is the quality triangle. Something we all know, but perhaps don’t place enough effort into understanding and actually realizing the impact it has on software testing – and importantly – software testing. The latter statement is especially important, as when we fail to understand and adhere to the quality triangle, it's essentially the testing in a project that suffers most.
What is the Quality Triangle?
For those new to software testing and unfamiliar with the quality triangle, I will explain it to you and why it is so vital to getting software quality right.
Typically, to produce quality in any engineering project even outside of software, you need to factor in three things: cost, scope, and time.
Cost represents the overall budget that will be spent on a project and in the software world, is largely based on the costs of people working on the project with a small subset also going towards tools and infrastructure.
Scope represents the size of the features and functionality that needs to be delivered.
Time represents the amount of time that the above features would need to be delivered by.
Essentially, to balance quality, you need to ensure that you keep these things in balance.
Trying not to do too many things too quickly will cause quality issues or require a reduction in scope to get the features out by a certain deadline. At the same time, having too few people on a project (or too few people lacking sufficient expertise or experience) will also slow things down or cause missteps in the quality of the final solution.
So, with the need to deliver software quicker, there is a bigger emphasis placed on balancing the size of the team and the scope that is delivered to ensure quality can be maintained. This may not always be feasible, depending on what work needs to get done but is typically managed in a modern Agile and DevOps world by releasing smaller things more frequently.
In theory at least. Because the reality is many organizations struggle to do this effectively and the reason is because of the way they approached the design of their software process, they did not factor in how to do so effectively with quality as the end result.
As testers, it's important to manage this quality triangle and not just test the software we are working on, but be aware of the scope, time, and cost of the project and find the best way to achieve quality within these constraints.
Although software testing is largely seen as an analytical or technical role, one of the most important attributes of any good tester is their ability to balance this triangle within a team. Which is a combination of both project management and interpersonal skills.
There is an argument that a product owner or scrum master would be better placed to manage this triangle and that testers should focus on their primary trade and test the software. However, in my experience, this doesn’t play out well. And the reason for this is focus.
While a product owner’s responsibility is to balance all the aspects of scope, budget, and time for a team, they will do this largely from a delivery perspective, which means they’re included to make decisions that favour delivery versus quality. And in a similar way, while a Scrum Master may be seen as more neutral, they’re often not close enough to the technical details that can provide the balance and are looking to unify the needs of all members of the team, focusing more on team cohesion and removing obstacles than a specific focus on quality. And thus, it often falls to the testers to drive quality.
Working Collaboratively
So, what a tester needs to ensure they work on, is communicating the impact all aspects of scope, time, and budget (team size) have on quality.
To do this effectively though requires getting your product owner, architect, and development lead all on the same page to understand your quality needs and trying to cater to them. This means you will need to use a bit of tact, cunning, and a bit of backbone to be able to fight your case.
But perhaps most importantly, will require a tester to be able to understand their different needs, meaning that you need to understand the purpose of the software and the development timelines well and engage on a technical level with the development team.
What About Automation?
And surely this is where automated testing comes in. To reduce the amount of time testing takes, teams and testers should leverage automated testing to allow for shortened regression cycles. And while this is true, it ignores the fact that thorough automation design and scripting takes far longer to script than traditional manual testing. By a significant margin. And this ignores any maintenance work that is required to just keep the automation framework and tests successfully passing.
The truth is that to make a success out of test automation requires alignment of the software planning and design process to meet the needs of testing. This all means that more time needs to be set aside to make provision for how the testing of the software will work – either in a sprint or part of a bigger project – and with this the impact on certain aspects of scope and time will be made clearer for the team and allow the tester to better manage this important triangle.
Am I living in a pipedream?
Now, most testers are probably reading this and thinking that this is never going to happen. Most projects and teams are never given enough time for planning – let alone planning that is centered around quality. This is why it is so crucial for testers to develop strong interpersonal skills and carefully work with the team to achieve this.
Although we live in a fast-paced world and need to deliver on our software deliverables quickly, the real benefit that a tester offers is in how they can improve on a team’s quality long-term and this is a game of patience. You’re unlikely to make any real headway in changing old cultures and behaviours in the first few months, but if you keep speaking about the importance of healthy test planning and the role that these attributes of the quality triangle have on the overall testing effort and quality of the software produced – you should start to see this change.