Testers + Scrum = ?

Several times I’ve had conversations with people who work with Scrum or Agile methodologies who claim they don’t have testers and don’t run into any problems. On the other hand, I have seen testers within these schemes who often feel excluded from the development team. Other testers who have not yet worked in Agile teams question whether there is even room for testers in Scrum.

It’s often touted that everyone in a Scrum team is able to perform different tasks and that all are responsible for quality. But, there are some things that a tester can handle better than others. For example, writing good acceptance criteria requires a tester skillset, as one must keep in mind and worry about certain characteristics such as quality, testability, maintainability, etc. These are all things that the tester role is responsible for obsessing over. Therefore, when you need to write acceptance criteria, you’ll be better off delegating it to someone trained in testing over someone that’s not.

So, can there be testers in Scrum?

Let’s Check the Manual

Looking for what the Scrum Guide says about the development team, I found this:

The Development Team

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of a “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.

Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.

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.

Individual development team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Analyzing the three points marked in bold, we can see that Scrum does not recognize roles or sub-teams, but there may be members with specialized skills and an area in which they focus. That is, there may be testers (with a tester’s skillset) that focus on quality tasks. However, the responsibility for quality is on the whole team.

From my professional experience, having worked with all sorts of development teams, including Scrum, I believe the “tester role” is still very relevant, as I mentioned in this article, “What is a QE?” A critical aspect of Scrum and Agile methodologies is that it is fundamental to have T-shaped skills, meaning that it is not only necessary to have the testing mindset and capabilities, but also to have some skill in the specialties of the people you work with, for instance, business, development, operations, etc. In such a way you can contribute more, making the team self-sufficient and promoting its excellence. Inside of our teams, us testers have to help shift testing left, allowing developers to test early and more easily, with CI/CD support, and then they can do pair testing, or the devs can test each other’s code. Anyway, developers still have a developer’s mindset, which is great for development, but not for testing.

A good tester can make a difference.

Speaking of Agile testing, here is a little reminder of the Testing Manifesto published by Growing Agile, which we love so much that we have it hanging on the walls in our Abstracta headquarters!