Testing is an activity, not a role

In traditional software development environments, testing may have been something that was outsourced. One group of people wrote the code and handed it off to a different team for testing. More recently, as the Principles of Agile were created and the Scrum framework in particular was popularised, cross functional teams have become the norm.

The Scrum Guide states:

Development Teams have the following characteristics:

• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
• Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
• Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
• Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

I’m a firm believer that testing is an activity, not a role. This mindset appears to be supported by the third, fourth and fifth points above. Getting to that state while forming teams from groups with well established specialisms can be difficult. Scrum as a framework for delivery doesn’t address this, but it; “functions well as a container for other techniques, methodologies, and practices.”.  A team that decides that Scrum is for them will need to think beyond its boundaries. XP describes techniques and practices that can help.

Teams that practice TDD are able to treat testing as an activity. Developers writing code can write unit tests (first), other Developers can write automated acceptance tests, and any manual exploratory testing can also be undertaken. If these things are coupled with keeping changes small, feedback from tests comes quickly and quality software can be delivered frequently with relative safety.

As a Developer I work with put it; “this requires discipline”.