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.