Stop Investing in QA

Over the past 10 years businesses learned about the value of QA and testing in general. Today every company has its own QA department that is making sure their software runs correctly. But the cost for these departments has become extremely high.

Will this trend continue or can we find new approaches to QA that are less expensive? 

Digital disruption

At the corner of my street is a Chinese restaurant. Yet when I order Chinese for dinner it's almost never from that place but from a restaurant that is not even located in my village. And it’s not because their food is bad. No, the sole reason is that the latter restaurant provides their customers with an app to order online. Existing customers like me can literally order their dinner in a matter of seconds.

This is yet another example of how businesses are being affected by digital disruption. This is not only true for small local businesses: large enterprises that have proven themselves for decades are also struggling with this digital disruption. Look at what happened to Kodak for example. These last couple of years, customers have been getting spoiled with digital solutions that make their lives a lot easier. And now with the explosion of mobile adoption, virtually every business has the means to provide their customers with those digital solutions. Customers are not only fond of these features, they are expecting them. Just like me, if I can’t order my dinner online from you, I will move to a competitor who can.

Change isn’t easy

Knowing about digital innovation is important. I’m quite convinced most large corporations are aware of the fact, but dealing with it isn’t trivial. I’ve seen this in the financial sector. Banks that have been slowly extending their IT landscape for the last 40 years, to improve their internal processes, suddenly have to start building enormous online platforms to compete with new digital players like PayPal.

Businesses recognize this problem and are investing heavily in their digital transformation. This transformation means something different for every business, but if they want to succeed, they should aim for a similar goal. They must learn what their customers find important in their products and deliver those features to them. Companies who can do this faster than their competitors will have the competitive advantage. When putting this into an IT perspective, it basically means that companies must speed up their product release cycles. By a lot.

Although companies are investing heavily in their digital transformation and have adopted practices like lean thinking and agile software development, they are still struggling with lowering the lead time of their product releases. There are several causes for this that are worth talking about, but one of the most overlooked causes for me is quality assurance.

Traditional QA

QA is a practice that has become apparent in almost every large company that is confronted with IT projects. Over the years, more and more resources have been invested in QA. On average, companies are already spending 35% of their project budget on QA and this number is still increasing rapidly. This can mainly be explained by the value that QA delivers to a company. Every defect found by a tester provides value for the project’s stakeholders and every fixed defect provides direct value to their customers. And now in this digital era customers can have a lot of impact on a company's reputation thanks to social media. To keep our customers happy we need our QA team to find all the critical defects. But projects grow more and more complex and business requirements keep changing at a faster pace which causes small QA teams to have a hard time dealing with the workload. This makes it feel intuitive to keep investing in QA, but if we look at how QA has evolved historically we can see this doesn’t necessarily make sense.

The problem is that in most companies a QA team is a team of testers that looks at the software as if a user was using it. It is an external view on the project and it is something that can only be done when the application under development has reached a certain level of completion. This makes traditional QA inherent to the waterfall approach. When a critical defect does get found by a tester the entire project needs to iterate the waterfall again. This is a very expensive and lengthy process. The defect needs to be fixed, the code base needs to be redeployed and the application needs to be retested for regression defects. This takes a lot of time for possibly just one feature that stakeholders want to push to their customers.

Test automation

I’ve seen a lot of attempts by companies to automate their functional regression packs just to mitigate exactly this problem. On paper this makes sense and for traditional QA professionals this feels natural because they look at a product from an external point of view. But investing in this strategy will not help you reduce your average lead times. More testers and functional test automation won’t solve this problem. Many technical experts know exactly what the pains are of investing in functional test automation. It's merely the equivalent of putting an expensive band aid on a wound that needs to be stitched. 

The road to quality at speed

In its early days, QA was a safety net that caught bugs at the bottom of the waterfall. Even customer-facing software just needed to 'work'. Today's QA teams are still seen as this safety net, but now they have to deal with a lot more aspects. We often forget that QA became way more than simply testing for bugs. QA is getting confronted with performance and availability SLAs, usability and accessibility requirements, flawed environments, projects that depend on legacy or external products and many more new aspects that simply were ignored in traditional QA. Investing in a bigger safety net is just not gonna cut it anymore.

Traditional QA teams can't deal with all these new aspects and because they sit at the end of the cycle many new QA aspects like usability or code quality stretch far beyond their scope. In order to speed up our releases, we need to start integrating QA with the rest of the project. We need QA professionals that know the business value of the project, understand the tech stack of the project and the infrastructure it runs on. QA experts will need to spread awareness and need to assist architects, developers, analysts ... into blueprinting the necessary measures which can assure the quality of the project in a rapid way. Those measures will be different for every project, but they will always target the same elements. They will have an impact on how our software is designed, how code gets written, how environments get set up, how we deal with data and so on. QA should be engineered into the project instead of on top of it and every project member should fulfill their role with a QA mindset. 

With this kind of QA we can finally move away from weeks of bug hunting on acceptance environments. Our acceptance environments can then be used by our business stakeholders as a private beta environment where they can learn even faster what their customers really want and how usable their products really are. Features for products that can be released in days instead of months will reduce the feedback loop between the business and their customers. For a company that is undergoing its digital transformation this is one of the goals that once achieved will help them outperform their competitors.

Obviously these are high impact changes that can't be made in one shot. But when testing cycles start taking days to complete, bugs are reaching production or customers start complaining on social media, maybe we shouldn't invest great amounts into our traditional QA department anymore. It might be the time to reevaluate how QA should be done in our projects and look for new partners who can help us with making those first little steps forward into achieving true quality at speed.

Are you looking for a partner that can help you take the first steps towards true quality at speed? Get in touch with our QA experts