Go to content|Go to the main menu|Go to search
Scrum is undoubtedly one of the most widely used agile methods for software development management. From my perspective, most teams, especially beginners, struggle with how to approach testing. In this article, I'll try to describe how testing is done in Scrum, what are the roles of team members, and where to place the tester.
In Scrum, there are three main roles: product owner, Scrum master, and developer. The role of a tester is not defined. Why this is so stems from the very definition of Scrum; the entire team is responsible for delivering functionality. In an ideal world, this would mean that every developer should be able to complete all steps related to delivery. However, it's hard to find someone who is proficient in frontend, backend, and testing. For this reason, in Scrum, we talk about developer specialization. We should therefore call a tester more of a developer focused on quality.
Now that we're clear on what role a tester has in a Scrum team, maybe we should stop using the word tester and replace it with the more general software quality engineer (SQE). A tester, in my opinion, is someone who performs the actual testing, which is only a small part of what we actually do.
I think from a psychological perspective, the SQE designation is better because it indicates that we can do a bit more than just click buttons. Would you rather have "tester" or "software quality engineer" listed as your position in your CV? From the results of Nicol Lindgren's Twitter poll, we can see that the job title is important for 56.4% of respondents (out of a total of 156 votes).
The number isn't high, but the poll deals with job titles in general. Personally, I'd guess that if the poll were more specific, focused only on developers, the number would be higher. I'd even bet that in the case of job advertisement titles, the name itself would have a big influence. Personally, I might not even respond to a "tester" position. "Software quality engineer" in my opinion indicates that the company is aware of how testing works and that they're not just looking for "clickers", but for someone who can cover a much wider spectrum of activities.
As written above, the entire team is responsible for delivering functionality. This means that the team pulls together, collaborates to make the best use of their specialization, and helps where needed. The team functions as a whole, and each member should lend a hand in all phases of development.
We often encounter "testers" acting as a separate unit and only getting to testing when everything is already done and developers are working on other tasks. In such a case, however, the team cannot function effectively because it's two teams with different goals. This inevitably leads to prolonging the time of functionality delivery. The priority of testing may be different from the priority of delivery. In practice, this can lead to a reduction in product quality:
Of course, the SQE also has a say in grooming and planning, and has the same voice as other developers in evaluating individual user stories. The evaluation must include testing. It's possible that for this reason, other developers will have "free hands" at the end of the sprint, but as already written - the entire team is responsible for delivery, and in case of time pressure, it's simply necessary to lend a hand. A good developer should be able to test as well.
It's important for the SQE to start preparing test scenarios and testing preparation as early as possible so that testing is ready even for the variant where one of the developers will be testing. After all, the test scenario itself is part of the product.
If testing is prepared but there's nothing to test yet, there are many other activities that are suitable to engage in regularly:
Regarding the last point, regression testing, it's worth mentioning that Scrum doesn't really count on it much. At the end of the sprint, the team should deliver a complete and tested product. This would mean that regression testing should be done at the end of each sprint. In practice, however, this doesn't happen, and usually regression testing is only done before a major release. Of course, it depends on what kind of product it is. In the case of microservices it's possible, but for large monolithic products it's essentially not realistic. From my own experience, however, I can say that it's good to do a "small regression" after each sprint. Focus mainly on the parts of the application that were changed and add a few more general tests.
Thank you! You have successfully subscribed to the newsletter.
