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 stated that everyone in a Scrum team should be 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 “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; and,
- 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 earlier, frequently 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.
In the words of Melissa Eaden, “Anybody can do testing, but only a tester can do good testing.”
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!
What do you think… is there room for testers in Scrum?
Recommended for You
What Is and Isn’t a Scrum Master
Not Convinced Yet About “Shift-Left” Testing?
Federico Toledo
Related Posts
The #1 Reason Why Agile Transformations Fail
Before turning your back on Agile, read this I’ve often heard that Agile transformation implies a paradigm shift, but what is a paradigm and why does it imply such a change? Anyone who has successfully made the shift can tell you that it’s not just…
Scrum, a Paradigm Shift for Software Testing
From waterfall to agile methodologies. What are the differences between Scrum and other frameworks? How does it represent a paradigm shift in software testing and quality? Find it out in this article written by Gabriel Ledesma, Leadership Coach at Abstracta and co-founder of the agile…
4 Comments
Leave a Reply Cancel reply
Search
Contents
I don’t agree the tester is required in a Scrum team. Especially when one knows that the development task takes some time before it’s available for testing.
It would be better to do this based on actual results. I would rather start with a team of “developers” who can test each others code and guide the other developer with pair testing.
I think the work would proceed much faster without the old way of thinking as a developer doing development and the tester doing the testing.
In my experience, there is a big difference when someone with the tester’s hat is embedded in the scrum team. Quality is the whole team responsibility, but there is one with the vision and skills, and mindset of a tester. But I guess, it’s hard to generalize, there must be cases where make sense other alternatives. The important thing is to try and see how it works in different contexts. That’s what Scrum proposes.
Regards!
Hello,
To make it happened we need to use Scrum’s extended ability and post-sprint retrospective period. When Sprint is planned then QA analyst should be present and take a note about new features need to be implemented in this Sprint and then the QA activities shall start in parallel so when ticket is ready to merge his test plan is ready. For bug fixes I use to complete it in Sprint retrospective period and completed tickets there shall be ‘’Closed’’. What’s help me is that I have intermediate status in JIRA workflow that allow to DEV to ‘’close’’ Sprint in the moment that quality control is in progress. Then is nice to have flexible buffer in the next Sprint allocated to bugs fix from previous Sprint. If no new bugs found them this marge may be used to add another ticket in to Sprint.
Best,
Vladimir
That’s the way, do, inspect, adjust/adapt, and iterate!