WavebreakmediaMicro - Fotolia


Does the DevOps tester really exist? Maybe, with some work

With the DevOps focus on continuous integration and delivery, is there room left for testers? Expert Justin Rohrman makes the case for why testers can still add value.

The companies that go all in on DevOps practices usually deliver software to the customer faster, sometimes more than once a day. The "package" they "install" includes tools that help them build and keep a pulse on software quality, without being inspected by a person. When the build is ready, the system can deploy to production -- in some cases automatically.

There's at least one promise embedded in that system: Testers need not apply. The promise that developers can deliver in a cavalier fashion without being "cowboys," not because of the safety net of humans, but instead because of a safety net in code.

Personally, I still think there is a role for the DevOps tester, or at least a person with deep testing skills.

Where have all the testers gone

If we imagine the host of tools in DevOps like a circus net below a trapeze performer, then the individual tools are the pieces of the net. First, there are the continuous integration (CI) tools that create a new build on every check-in and run some automated checks. There are also tools designed to automatically deploy a new build when it passes tests. And there are all kinds of programming tools to help check work like test-driven development (TDD), behavior-driven development, tools to check the service layer and tools to drive a browser.

Testing does happen there. The programmer has to think of a way her code can fail and test for that. Then when the problem actually happens, she has to investigate why, what the cause is and what a fix might be. But the way these tools are used individually tends to be shallow and comes from a different mindset, a creation mindset.

Let's say a very small check is written to see that the variable for a bid is updated to five when a value of five is submitted. The test is written; the code is written; and from then on out, the focus is to keep that test passing. Development can be risky if I choose only one of those frameworks -- TDD, for example -- to build a product. We would end up with a set of checks, but only from one perspective. Things get interesting when they are layered, though. Even though the checks are simple and maybe shallow, we get to a pretty good place with code quality. Annoying problems like dead on arrival builds and failures from submitting become much less common.

When people get to this place where developers care and code quality isn't terrible, the need for mass inspection -- that army of testers grinding away on the product at the end of every release -- shrinks. We still need DevOps testers, but there may be fewer, and they may be doing some nontraditional things.

The hybrid tester

The companies I see that went the full-automation route have a couple of slots for a hybrid tester, but just a couple. Instead of toiling away in the dark waiting for someone to throw them a new build so they can fire back with bug reports, these hybrid DevOps testers are heavily involved in the technical work. Some of this happens through tester and developer pairing. For example, if a programmer is building a new API endpoint, the tester can act as a sort of backseat driver making course corrections, asking questions and beginning the work of building some automated checks. By the time the programmer is done building the production code, there is some automation that can be added to the CI system that checks the product in a more complete way. In some companies this is done by the two roles pairing all the way through the story, but it's more common that the two split for work and periodically connect.

The benefit here is that together they can find problems in a development environment and save time by getting them fixed before they hit a test environment. Shrinking the number of times code is handed off between people saves some time. There is another benefit in pairing that is the DevOps tester asking questions that a developer focused on creating code -- and maybe not so much on how it could fail -- would have never come up with otherwise.

The other, more technical, side of this is learning a new skill set in programming and using tools that would normally only be used by programmers. Companies making heavy use of DevOps, especially ones that use extreme programming and near constant pairing, might not have a role for a tester that doesn't know how to write code. The programming DevOps tester can jump from helping a production programmer test her changes, to writing code that will automate checking different parts of that code, to working on the CI system. They are more versatile and can work through testing problems at different points in the team.

That is the ideal, but aside from a handful of companies in Silicon Valley, most companies aren't there yet. The talks I hear about at conferences describing layers of automation and awesomeness with no testers are pretty far off from average. Change is definitely coming, though. I am investing in my skills and preparing for the future DevOps tester role.

I think you should be, too.

Next Steps

Why testers need to embrace change

When it comes to testing, nothing stands still

Here's how to get ready for a software testing job

Dig Deeper on Topics Archive