In my first job as a software developer, my tester sat right next to me. Sandra, a clever and experienced tester, cast a skeptical eye over my code and was quick to find all its problems. She seemed to know all the newbie developer mistakes I was going to make, before I made them! Sandra had hilarious stories about software going wrong and the crazy lengths she’d had to go to in order to reproduce customer problems. She taught me a lot.
As a result of my product’s success, the team grew. Testers were organized into a separate team managed by a test manager. Even though I missed having Sandra sit next to me, I could see the advantages. The testers became a strong team with a growing sense of community. They exuded energy and enthusiasm as they came up with creative new ways to break my code!
Throughout the 30+ years of my career, I’ve regularly seen two approaches: Sometimes testers are embedded in the development team and sometimes they’re in a separate team.
In my experience, both approaches have advantages and disadvantages.
To embed – or not to embed – testers
Embedding the testers into the development team fosters stronger and more harmonious relationships between development and test. It strengthens the quality mindset in developers. Testers have a better idea of exactly what the development teams are doing, allowing them to be more proactive and incorporate testability into feature development. They’re better able to find problems.
On the other hand, embedding testers into the development team can also have downsides. It puts an organizational barrier between testers in different teams. This makes it harder for testers to share information, skills, knowledge and new approaches. In the worst case, the manager – who came from a development background – downplayed the concerns of testers and released software with poor quality.
A separate testing team, especially one with a strong leader skilled in test methodology, has big advantages too. The sense of community, teamwork and learning in a focused test team can be galvanizing. Such test teams have their own identity and a strong voice in decision-making about product readiness. The level of creativity goes up as more minds can be rallied to focus on a specific problem.
On the other hand, a separate testing team also has downsides. The bond between testers and developers is weakened and testers are less informed about the development team’s work. Sometimes developers focus less on quality. In the worst case, there is more conflict and there might even be an us-vs-them mentality.
Like many companies, Kinaxis has tried it both ways. When I started three years ago, the test team was consolidated under a strong leader. This worked well. As Kinaxis has embraced the Agile methodology more and more, we’ve integrated the development and test teams. In my organization, the testers and developers now all work together in integrated scrum teams.
How are we going to mitigate the downsides of this organization? Stay tuned for our next blog to hear more about what we tried and how it turned out.
Leave a Reply