Will Continuous Integration (CI) and DevOps Mean the End of the Traditional QA Skillset?

Testers who have been working in the industry for a while know that one of the undeniable characteristics of software development is change. Often, when an innovation in workflow or technology comes along, testers ask themselves whether this new change will put their jobs at risk or force them to retrain. Is this something we should be asking, given the adoption of DevOps as a workflow by many organizations?

Increasingly, DevOps methodologies are becoming the standard in software development. There are some attractive reasons for companies to adopt this workflow, chief among them is getting the product out fast. Depending on the scale of the development effort, software builds can happen anywhere from a few, to hundreds, of times a day. With each check-in, a suite of Automated tests is triggered that cannot only check for regressions, but can also measure performance and test security.

With all this Automation, it is tempting to say that the role of the tester is diminished, but this would be false. In fact, testers’ duties do not change very much with the adoption of a DevOps workflow. Testers that were writing Automation are still doing just that, while those that are exploratory testing specialists are still valuable for their unique approach. A solid bed of test Automation allows testers to do what they do best: ask questions and identify ambiguities.

Everyone on the development team will be thinking about the tests that are part of the Continuous Integration (CI) pipeline. If those tests fail after a build, the first task is to fix the code to make the tests pass. This will get coders or QA Automation specialists to make sure that they are writing smart tests, ones that do not return false positives or negatives, and stable ones as well. It is important throughout the development life cycle to keep asking the questions, “What are we testing?” and “How are we testing it?”. Exploratory testers can also participate in these conversations by surfacing risk areas and suggesting other tests that coders had not thought of.

CI has brought us the notion of Infrastructure as Code. The setup of a server and its configuration are no longer manual processes; they are captured in a series of instructions and executed automatically. A CI pipeline is comprised of multiple stages of building, testing, and deployment, frequently across multiple environments. While these pipelines are normally built by developers or DevOps specialists, QA can test the pipeline itself. Testers ask questions like, “What happens if this stage of the build fails?”; “What state will the system be left in?”; or “Will this have damaging effects?”. Infrastructure as Code is also meant to be scalable, so testers need to ask what happens when the code is made to provision larger numbers of configured servers.

Is it mandatory for testers to be able to write code in order to work in a DevOps environment?

The short answer is no; testers who are not code-literate still have a lot to contribute in terms of their exploratory testing skills as well as their powers of critical thinking. Having some code literacy is definitely an asset though, and worth considering when a tester is looking to broaden their skillset. In addition to writing Automation, testers with some code literacy can create helpful tools that work with, for example, monitoring systems.

To conclude, working in a DevOps environment should not cause a tester’s job to vanish. Instead, it builds on a tester’s toolkit of already existing skills such as critical thinking and risk analysis. It also makes for a great working environment for testers, as now, more than ever, there is a focus on quality by all team members.