Building Alliances Between Testing and Other Teams
- The Software Test Team and the Development Team
- The Software Test Team and the Product Design Team
- The Software Test Team and the Customer Support Team
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
With its frequently frenzied pace, the software development process can create a complex, tension-filled work environment. I've seen team dynamics where people feel pitted against one another, forced to fight for resources and time. The more political the work environment, the more challenging it can be to create trustworthy professional relationships. And yet, it's in exactly those difficult politically-murky work situations where we need trusted contacts even more. In trade articles and at conferences, we seem to avoid talking about difficult work environments—as though our challenges are just technology and deadlines—but the reality I've experienced is that people and team dynamics are often the bigger obstacles.
There are ways to create healthy professional relationships. Part of having a relationship is sharing a sense of connectedness, so it might be expected that building a product together would offer that sense of connectedness. Certainly, in high-functioning, healthy, level-headed environments, overall team dynamics are less of an issue. But what about in other environments, where the dynamics are sour? How can solid working relationships be exemplified and encouraged?
Building alliances in politically heated environments takes focused, concerted effort. Building an alliance goes beyond just building a relationship—alliances are about reciprocal relationships that take hold. Alliances are intended not just to foster a collaborative spirit, but to find ways in which teams can look out for each other and work together.
Given the specific elements of building a software product, there are three pairs of teams for which having strong, healthy dynamics is especially helpful:
- The software test team and the development team
- The software test team and the product design team
- The software test team and the customer support team
In this article, we'll examine the three types of software development pairs and consider some real-life examples of how to go about building alliances.
The Software Test Team and the Development Team
In this work environment example, a product being built was for internal use. The product owner, Sheila, was a business user who was selected to oversee product development. Although she had extensive knowledge of the business, her experience in working with the software development process was limited, and she didn't ask enough high-level questions to expand her knowledge of the process to a comfortable state. The software developers and testers were unfamiliar to her, as most of the team consisted of newly hired consultants.
Some communication gaps had already taken place by the time I joined the team. Involved from the early days of the roughest product builds, Sheila was becoming skeptical of the product because she couldn't decipher the information that was being given to her. Now, the product concepts and design had been worked through, the product was being built, and unit testing was starting in earnest—but even the concept of unit testing was unfamiliar to Sheila.
As an outside consultant brought onto the project to map out testing, I made myself available to answer questions related to testing (or any other topic on which I could assist). In this role, I became somewhat of a translator for Sheila, from the technical jargon to the business side of the project. We had multiple conversations regarding the planned design, implementation, and execution of the unit testing. Sheila was slowly learning more about the development process and what unit testing actually meant. She gained confidence in what the developers were doing and began to be less disturbed about the defects that were being found as the product continued to evolve.
I worked closely with the development lead, discussing unit testing, offering ideas to be integrated at the early stages of development, and overall gaining insight into how unit testing was being structured. I also learned what was being tested at the unit level, which simplified assessing how and where testing might pick up, and where to fill in ideas for mapping out a test strategy.
Sheila began coming to me for my opinions about the development efforts. I was able to allay her concerns about unit testing overall by answering questions like these:
- Why is unit testing so important?
- Why shouldn't unit testing be viewed as optional extra work?
- How does unit testing strengthen the product?
By taking on the responsibility of acting as a liaison and interpreter for Sheila, I relieved the development team of having to explain what they were doing. Somehow, an outside consultant, I was better able to confirm what the development team was doing, resolving the mystery and confusion of the process for the product owner. Being in the role of communicator between the product owner and the development team helped me to foster a strong relationship with the developers. They came to recognize that spending time with me, answering my questions, and planning with me offered benefits beyond just what I needed or the testers needed. It was a stroke of good fortune, perhaps, but I've seen elements of this scenario played out in other circumstances. Sometimes a team cannot speak for its own efforts to a project stakeholder as well as someone else can.
Here are three additional opportunities to build good relationships between the testing team and the development team:
- Defect detection: First areas of focus. Many times I've coordinated with a development team to determine where to focus some of the first bits of testing. This alignment of priority tasks helps to build a shared sense of risk. Of course, testers can't always find the most important defects first, and sometimes the next iteration produces a new nasty regression bug. But having an overall understanding of what's important and focusing everyone's efforts in the same direction brings a natural alignment between testing and development.
- Defect priority: Understand what's important. Defining what will constitute a high-priority bug versus a low-priority bug also helps. Priority setting is like having a shared risk assessment: Aligning thinking aligns the teams, helping to ensure that everyone feels, "Hey, we're looking at this product in the same light."
- Good end-game behavior. When the release cycle gets down to the end, tensions are higher. In some settings, I've seen developers take tremendous pressure from executives when defects are found late. It's important to be aware of the dynamics that take place at the end of the cycle and try to do what you can to avoid adding to the tension. Once other teams have experienced that you're someone who works fairly, alliances begin to form.