You know how some topic will come up, and suddenly you notice it’s coming up over and over in different contexts? Lately, for me, that topic has been collaboration among roles on software teams.
My own team practices a “Whole Team” approach to development, and we testers work closely with the developers on a daily basis. Still, testing and support (all three of us testers do both) are, organizationally, a separate team with our own manager, who reports to the same director as the development manager. On top of that, our company didn’t even have testers before it hired the first tester on our team. Except for our team, which works exclusively on a software product, our company builds software for clients. The teams all do test-driven development, and automate tests all the way up to the GUI level. The clients’ testers help with acceptance testing. Testers have been hired on a contract basis, but not as permanent team members. So, there hasn’t been a culture of having testers, or really any people in different roles, on the project teams.
The developers on our team often express their appreciation for having testers on the team, we feel welcome. We generally collaborate well. And yet, there are impediments. Like all teams, we’re juggling many priorities. What’s important from our tester perspective might not match the top of the list for coding or for the product owner.
We continually think of experiments to work more closely with other roles on the team. For example, I got to pair with developers to write and automate customer-facing tests to drive development of our new API version. I found it hugely productive, but the team decided it was better overall to have me specify the tests on the wiki, and have the pair coding the story automate the functional tests. That’s why we experiment, to learn quickly what works best for the team.
More recently, we testers met with the designers on the team to brainstorm ways we could help each other. We now have some collaboration experiments underway that we think will improve the user experience while helping us think of more test scenarios.
I meet many testers who feel isolated from other roles on the team. They want more collaboration, but organizational or physical barriers get in the way. How can these testers find ways to work more closely with programmers, analysts, designers, business experts, and others? I think one component is finding better ways to share knowledge and help people learn so they can communicate. For example, testers with technical awareness, who know programming basics, understand their product’s architecture at a high level, and use an IDE and source code control daily, find programmers much more willing and able to communicate with them. As Rob Lambert has pointed out, these T-shaped skills help us overcome a phased approach to software development. Jesper Lindholt Ottosen recently suggested ways testers can organize and recognize our skills.
If you have testing problems you’d like to solve, think about who else besides the testers might be able to help you solve it. Though everyone gets involved in their own problems, you all have a common goal: deliver software that delights your customers. You’ll probably find that if you ask someone in another role for help that they’ll be eager to brainstorm possible solutions with you. At the same time, find ways you can help with other peoples’ problems, even if it means stepping outside of traditional “tester” activities. Pete Walen recently pointed out some non-traditional ways testers can understand business needs better. I personally think that blurring the boundaries between roles and bridging the gaps is the best way to advance the art and craft of testing.
I’d love to hear how other people have bridged the gap between different roles involved in producing software. Please add a comment here, or email me! Janet Gregory and I would love to have stories about this to include in our new book. Examples of how testers can collaborate with other roles will give those testers who feel isolated ideas they can try.
I hope this topic will come up in my “Advanced Topics in Agile Testing” workshop at Agile Testing Days. We’ll have a great group of people who will forge some new frontiers in testing!