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.

While the above discussions start off the implementation on the right note, a lot has to do with how the testers handle themselves. They need to understand the true meaning of empowerment rather than seeing it is as something management gives them. Short of a “quota” of stories, testers may have to define improvements so small they can be done over a few lunch hours, and pair with programmers to get those to happen.

Along the way, they can bring in some fun factor through practices such as weekly or monthly exploratory testing exercises, bug bashes, etc., which will also help the rest of the team understand testing practices and management systems in an effective manner. It is important for testers to showcase the new tasks they are taking on, whether it’s interacting with end-users, focusing on building quality in end-user expectations, evaluating the quality of the product in line with competition in the market, looking for more optimization in test efforts, or enhancing levels of test automation. It is also smart for the tester to work cohesively with the product team in enabling quality, additionally leveraging tools wherever possible.

However, there is a question that often restrains testers from taking these actions: What if I don’t get credit and recognition for what I have done? I am not asking team members to give up on their career progression goals; once you understand that it takes two people to either make or break the relationship and you apply this idea in a constructive manner to truly collaborate, it is not just one individual’s career, but the entire team’s progression that will get a positive facelift.

This kind of collaboration calls for free-flowing knowledge, sharing tools and frameworks, ease in accessing people whenever needed, and a true belief in the model of teamwork. When this happens, any issues can be resolved in a mature manner, and it means the tester has really been accepted into the DevOps fold.