Accepting the Tester into the DevOps Fold

[article]
Summary:

Today’s tester has moved upstream, along with the test processes, where he is involved right from the product design stages. This can create great opportunities for the team to bond, but if not handled well, it can become a breeding ground for strained relations. Adopting DevOps means promoting collaboration.

The software community spent most of the 20th century trying to “get things right” at each stage, preventing the need for collaborative give and take. Just slide the spec under the door and let me code, test, or deploy; if things aren’t clear enough, that’s your fault.

Most teams we work with don’t think like that anymore.

Instead, now there is a different assumption—that there is a need for more collaboration among the product development teams to survive in the marketplace. The very idea of the team is expanding to include analysts, management, HR, and even sales (which some now call “growth hacking”). That collaboration yields fruit, not just in the bonding of the team, but also in the quality and competitiveness of the product under development. It’s not rocket science, but the true challenge lies in changing our behaviors to implement such a model, especially between the testers and the rest of the product team, in a win-win manner.

Today’s tester is no longer involved in merely executing test cases and reporting results. He has moved upstream, along with the test processes, where he is involved right from the product design stages. For instance, application performance considerations are being discussed up front and built in rather than being merely benchmarked and tuned later on. And the tester plays a critical role in such discussions, bridging the gap that long existed between development and quality.

While the tester is typically still on the hook for quality issues found in production, this new kind of product team understands the role they play in contributing to a quality release. This allows the tester to transition into a role where he is empowering the rest of the team to truly own quality—helping the developer build unit tests, enabling the build engineer and developer to leverage a powerful set of automated tests for a quick sanity check, etc. All these actions can create great opportunities for the team to bond, but if not handled well, they can also become a breeding ground for strained relations. The technical staff might see the tester as “trespassing on my turf” or, perhaps worse, “trying to get me to do his job for him.”

Getting Real about DevOps

And then we have DevOps, where we are explicitly trying to get the programmer to automate portions of a more traditional role: building, provisioning, checking, and deploying the servers and the software through tools.

The classic argument here is that programmers program. They automate things. The tester understands what parts of the work can be done repeatedly with consistent correct answers—the “checks”—versus what part requires human judgment. The tester can then become a sort of product owner for the requirements of the automation … and then has to compete with the actual business requirements. Who do you think is going to win there?

You could try getting senior management to buy into this change; get them to explain it during an all-hands meeting, then department meetings. Line management could explain the new division of labor and come up with a strategy to decide a percentage of the work that goes to DevOps versus new feature development. That’s a fine approach, and worth trying. But for testers, getting that to happen is a bit like pushing a large rock uphill. It’s a lot of effort, and if you ease off the pressure for more than a second, everything can come crashing down, leaving you worse off than you started.

User Comments

1 comment
Al Hackett's picture

Thanks for the article. In my opinion some problems with testers may begin with the fact they don't feel as a part of the team. The question's: how to make them feel so?

First of all, treat them in a serious way, respect their work and their role. Treat them the same way you want them to treat the other team members. Testers are often IT begginers so the real team-spirit atmosphere they experience in our team may stay in their memory for the whole professional life ;) From my experience to buid a team spirit every-day communication's what works quite well - not only the chatting and coffee moments but online reports of current actions, like shared excel document or intuitive and clear boards like http://kanbantool.com/product . My last team got so engaged in planning things by Kanban that they put coffee breaks on the board too ;)

Summing up, don't forget to share the boards with the testers too! They ARE the part of the team. Observing what's being done in the whole project gives the testers chance to organize their time, as they may predict when they'll be given another tasks. More, it may give them new motivation to develop themselves, to start doing other things, additionally to testing :)

March 20, 2017 - 6:56am

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.