My last post: Testing is an activity, not a role, prompted a few comments on Twitter from my friends in the testing community.
Most people didn’t think the post went far enough in explaining that although testing may indeed be an activity, it’s probably more than one activity, and that different activities require different skill sets. I want to address some of that here.
In essence, I’m referring to software development as a team sport, the difficulties that arise when trying to evolve to Agile delivery methods from more traditional delivery methods, and how we might go about breaking down those barriers between Development specialists and Testing specialists, promoting the team ethic. Everyone is responsible for quality, therefore everyone should undertake some form of testing. What testing is undertaken by each team member will probably be determined by their chosen specialism.
So how do we go about breaking down those old barriers? Should the whole team understand the chosen automated test framework? Should a Product Owner be able to write conditions of satisfaction in a Given, when, then format? Should any Developer in the team be able to pick up any story regardless of language or technology?
The answers to all of these questions could be yes, but as always, context is key. Some teams may have a good balance of Developer and Testing Specialists, some may not. Architecture will also play a big part in determining what testing may take place, and when.
When making the transition from a traditional delivery method to a more modern approach, the important thing is to put an emphasis on working together as a team. The team can then define what testing takes place, who does it and when, taking into account the skill sets at their disposal.