As technology develops, and our expectations grow, we all want more from digital services and the experiences we consume.
This puts pressure on the businesses creating the apps and products that underpin those moments. They need to deliver things quickly, be perfect, and at a price people are willing to pay.
Wanting it fast, perfect, and cheap
This contradicts the adage that you can have something fast and good, but it’ll cost you. With markets demanding that costs remain relatively as low as possible, businesses have to find ways to create margin within strict parameters. In other words, they’ve got to cut the price of production.
What that price looks like will differ from sector to sector. Sometimes it will be hard cash; other times, it will be speed. In software development, companies always look for ways to get to market as quickly as possible, reducing costs. And one area where there is cost (as in speed, or lack thereof) is quality assurance.
No one wants to release bad products filled with bugs, yet the demands on getting apps into the hands of users mean the time spent on QA is often not what it should be. Either QA personnel spend less time per product, or they end up bottlenecking production.
Do you know what QA is?
This is exacerbated by a lack of understanding of what quality assurance is. Many companies fail to differentiate between testing and quality assurance and assume that having a testing programme in place will automatically deliver high-quality software. The blame is placed on testing when the end product has bugs or fails to deliver an expected experience.
That’s the wrong way to look at it. Testing is pass/fail. It is an essential part of checking quality but not an entire QA process.
It’s a bit like learning to drive. A tiny minority of people might be able to pass a driving test without learning to drive first, but the vast majority need to have lessons before they attempt a test. The lessons are, in effect, the process of embedding quality in an individual’s ability to drive. In safe conditions (i.e. with an instructor alongside the learner), skills are developed until they reach the required standard.
But learning to drive isn’t just about passing the test. While the initial goal is to get the individual to a point where they can pass the test and drive unaided, the lessons are about laying the foundations for ongoing learning. So when the driver has their full license, they know how to react safely and legally to driving in real life.
And that’s what’s missing if companies think that testing is the same as quality assurance. They need to come up with the software development version of driving lessons to not only ensure their products pass tests but have the necessary foundations to meet stringent quality standards.
Time to build a culture of quality
What does that actually look like? It’s about building a culture of quality throughout the organisation. Developers do a tremendous amount of work to get products ready for testing. How frustrating is it if QA is only brought in toward the end? It would be more efficient to embed the principles and practices of QA throughout the development process. That way, issues could be spotted as they develop rather than when the product is 90% complete.
Let’s be clear, this isn’t a call to get developers to do QA and remove the QA team; the latter is still very much needed. But they don’t scale, and as demand for speed accelerates, having QA embedded through the development lifecycle is one way to maintain quality throughout rather than having it as a bottleneck just before products are released into the market.
And this concept of ongoing QA includes continuous testing. Rather than one big test at the end of the process, building in regular testing helps catch problems earlier. Again, doing this at scale can be challenging, but teams can run multiple tests simultaneously with continuous automated testing. Testers can focus on checking for accuracy rather than running the tests themselves. In this way, the quality of products can be maintained without causing delays.
Embedding quality throughout
Many people fail to differentiate between testing and quality assurance. But not wanting to mix them up isn’t just a case of pedantry over semantics; assuming the two are interchangeable is a shortcut to failure. Quality needs to be a goal, and it cannot just be checked towards the end of the development cycle; it needs to be embedded into working practices. As business demands for speed and quality increase, ensuring that QA is built in throughout is the only way teams can ship products, services and applications that meet users’ needs while matching the speed to market everyone expects.
