.svg)
.svg)
With the industry evolving rapidly around us, there’s little room for anyone who isn’t able to change at pace. A six month old greenfield codebase will be brown before you know it. You must be able to move quickly.
How can tech teams unlock the true value of their work?
The quality dilemma
I see this in the QA community. Every forum I see is full of questions and conversation about writing scripts. Every job description focuses on the need for coding skills. Meetup agendas are usually packed with talk about the latest automation tools.
Automation is an important part of testing, and testing is pivotal, but this is no reason to turn our QAs into specialised developers. Automation is just a part of QA, not a synonym. Coding skills are of course vital, but by no means a recipe for quality success.
Where has the quality gone? QA is short Quality Assurance after all…
Overgrowing one part of QA means you starve the others.
Overgrowing one part of QA means you starve the others and this is a risk you just can’t afford to take. By looking to automate, standardise and make recyclable components, we’re becoming faster, sure. But faster alone is not enough to produce quality. The real value lies in finding a balance between the two.
As QAs move more and more into coding, there’s an unspoken expectation that we’ll be a quiet ‘geek’ in the corner. But these teams need someone to be vocal. To be the champion of ensuring value in the tech.
Rediscovering quality
Quality = fast + secure + robust + flexible. We can only achieve this by looking at the right questions, encouraging interdisciplinary collaboration and asking our QAs to look at the entire system, not just the software development part. We need to better balance testing and automation with other quality activities using a more diverse set of skills. That’s where we can add the most value.
As the tech industry is approaching maturity, more companies are building software. Healthy competition starts to arise. And in order to succeed, it’s not enough to simply deliver a product - you need to constantly iterate and add value.
My experience has shown me that, for now, in the software building industry, this is not common.
How long will people be satisfied with products that offer nothing different from what already exists?
So the question is, how long will people be satisfied with products that offer nothing different from what already exists, simply because they are quick to reach the market?
We should try to find the answer by rewriting the quality book and allocating more room to the chapter where we strive to find ways to improve the system as a whole. By redefining what ‘better’ and ‘success’ mean for the team, or by rethinking what skills we need and how diverse our team needs to be.
If we do all of that, we’ll create a competitive advantage for whatever product we choose to build next.
