When most people talk about software testing, they assume that every organization has a dedicated team of Quality Assurance (QA) engineers whose main job is to test software and optimize software quality.
The reality is that not all organizations have a QA team. When your company lacks dedicated QA engineers and software testing experts, everyone else who plays a role in software delivery needs to work extra hard to fill the gap. Keep reading for tips on how to do that.
The missing QA team
Some companies just don’t see the value in hiring QA engineers. Others might believe (falsely) that in a DevOps world, you no longer need to have a dedicated QA team. And then, of course, some companies are just too small to have the resources to hire full-time QA.
To a limited extent, companies can try to fill the QA gap by working with freelance QA engineers. That might work if your company does a very minimal amount of software development, but it’s not practical or responsible for a full-scale CI/CD pipeline. Relying on freelance QA engineers means you will lack the consistency and full coverage of having QA engineers on staff—which is bad, because QA is not something you can do on an ad hoc or case-by-case basis.
You could also try to fill the gap by hiring developers who also have software testing experience. They exist, but they are hard to find. They also generally cost quite a bit, so in many cases, you’d be better off just hiring full-time QA staff.
Doing QA without a QA team
The good news is that lacking a full-time QA team does not mean your organization has to compromise on software quality. With the right approach, you can fill the gap using the developers and IT staff you already have on hand. This might sound intimidating, but it’s not. Even if you do have a QA team, your QA engineers should be working closely with developers and IT; after all, that’s what DevOps and QAOps are all about.
What changes when you don’t have a dedicated QA team is that your developers and IT engineers simply need to play an even more active role in QA operations. Instead of just communicating and collaborating with QA engineers, they will need to get more hands-on with software testing and software quality optimization.
Strategies and practices such as the following can help developers and IT engineers do that, even if they don’t have prior experience in QA:
Developers can write automated tests. Developers already know how to code — it’s what they do all day long — so learning an automated testing framework and writing tests for it is not a huge issue for them. If you have developers on staff, you don’t necessarily need QA engineers to write your automated tests. (Even if you do have QA staff, developers can always assist in writing automated tests.)
IT engineers can contribute to “shift-right” testing. Shift-right testing means performing testing in production. In a sense, that is what IT engineers already do when they monitor applications. To get your IT engineers to play a more hands-on role in QA, ask them not just to monitor for problems, but also to look for ways to use production monitoring insights to improve overall software quality.
Continuous feedback. Without a full-time QA team, there is no one to make sure that developers know about software quality problems that arise in production (and are detected by IT engineers). Nor do IT engineers have a good way of knowing how developers expect an application to behave. That’s why it’s important to establish a continuous feedback loop directly between developers and IT engineers, so that each team can discuss software quality issues with the other team.
Collective ownership of software quality. From a cultural perspective, every developer and IT engineer should share in ownership over software quality. This should happen to a degree even if you have a full-time QA team. But in the absence of QA, there is no one whose primary job is software testing and quality; as a result, it falls to developers and IT to own QA completely.
Be efficient. It’s hard to sell developers and IT engineers on owning QA if they think it will mean more work and time. That’s why it’s critical to empower them with tools to make QA efficient, such as test automation (which eliminates the need for humans to spend time running tests manually), extended debugging (which helps interpret test results quickly), and parallel testing (which allows more tests to run at once).
In a perfect world, every company would have a large and dynamic team of QA engineers who spend their days perfecting the quality of every code release that comes down the CI/CD pipeline. In the real world, lots of organizations don’t have QA teams at all, or lack ones large enough to handle all QA obligations on their own. That’s another reason why making QA the responsibility of everyone involved in software engineering is so critical.
Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, agile infrastructure and networking. He is Senior Editor of content and a DevOps Analyst at Fixate IO. His latest book, For Fun and Profit: A History of the Free and Open Source Software Revolution, was published in 2017.
