
Invitation to AMPER 2025
We invite you to AMPER 2025 - the international trade fair for electrical engineering, electronics, and energy.
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.
We invite you to AMPER 2025 - the international trade fair for electrical engineering, electronics, and energy.
Creation, maintenance and orchestration of virtual environments is part of software tester’s daily routine on most projects, especially when working with desktop applications. Virtual Machines (VMs) help you create isolated environments with different test configurations on a single machine eliminating the need for multiple pieces of hardware.
In an interview with Voices of Industry, Jiří Baroš, CEO of Edhouse, shared his professional journey and discussed how modern technology is shaping the direction of our company. The interview, recorded at the International Engineering Fair in Brno, highlights the growing influence of software and hardware in engineering and the importance of technological developments for process optimization, efficiency improvement and data processing.
Thank you for your interest in subscribing to our newsletter! To complete your registration you need to confirm your subscription. We have just sent you a confirmation link to the email address you provided. Please click on this link to complete your registration. If you do not find the email, please check your spam or "Promotions" folder.