Articles | August 16, 2019
Tester’s role in a Scrum Team
Self-organization and lack of hierarchy – this is what Scrum as a framework offers in contrast to other known management models. The traditional boss – team model has been replaced by the Development Team, wherein every single person is a Developer: a person who contributes to a project’s success. Many people, on hearing about Scrum, ask questions like: what about the tester’s role in a Scrum Team? Is the tester a full-fledged member of such a team?
Hierarchy in a Scrum Team
The question about a tester’s value as a member of a Scrum Team is actually a question related to the hierarchy in a Scrum Team, meaning who is responsible for organizing the team’s work. Would it be a Product Owner? It is the Product Owner’s role to manage the client’s product, not the team. He is not responsible for supervising the team’s work. So maybe it is the Scrum Master’s task? According to the Scrum Guide: a Scrum Master is a servant-leader, which means that he identifies the team’s needs. He does not manage the team, but through observation, takes care that Scrum rules are respected. So maybe developers should manage their work on their own? This also doesn’t seem to be the correct answer. Who then? Actually the entire Development Team – altogether and thanks to continuous communication – makes decisions and manages their own working time.
Tester: traditional model vs. Scrum
It is important to comprehend the tester’s role in such a self-organizing team. In the waterfall model, apart from particular hierarchy and roles, there is also a defined workflow during development of the project. In this model, the project enters the testing phase once developers finish their work.
In the Scrum framework, the tester does not wait until the end of development work for testing but cooperates with other members of the Development Team during defined Iterations – Sprints. This enables the verification of the work of the Development Team at each stage. Additionally, limiting the tester’s role in Sprints to only the testing of functionalities would result in not allowing him to reach his full potential and wasting time between implementations.
Working with remote teams in the same or a similar time zone, known as nearshoring, seems to bring about advantages and challenges in equal measure.How to work effectively with Agile nearshore teams? Read the text to find out more!
Tester’s role in Scrum – common myths
There are many myths about the tester’s role in a Scrum Team. The most widespread is that the tester’s role is redundant, because every member of the team has the relevant competences to develop valuable functionality. Such a belief might issue from misunderstanding the definition provided by a Scrum Guide, which defines the Development Team as cross-functional and with all the competences required to deliver an Increment; however, it does not define the particular competences of team members.
In Scrum everyone is defined as a Developer, meaning the person who co-creates the product. The tester should be actively engaged in the team’s work during the Sprint and meetings. It is the tester’s role to ensure the quality of the developed product and the delivery process itself – for example by mastering the product’s Backlog, which I will discuss further later in the article.
Another, in my view harmful, myth is that there is no place in Scrum for tests other than automated ones. In Scrum each Sprint is different, which calls for flexibility in the context of planning, running tests and analyzing their results. This work must be undertaken by the tester himself, and it is his responsibility to select the type of tests and define how detailed they should be, based on risk analysis. All team members should help in these actions, in order to deliver the best possible product together within a particular timeframe.
How to do it? I will respond evasively: it depends. Unfortunately, there is no one single remedy. I may advise junior testers: strive to be team members not only by definition. Try to actively participate in the whole delivery process; such an approach will let you swiftly gain knowledge and experience. This will result in improved planning and organizing within every upcoming Sprint, and the work of the whole Development Team will be better and more efficient as a result.
Tester’s tasks within a Scrum Team
Mastering the Product Backlog
Many people wonder how a tester engages in team activities. Let’s have a look at a tester’s possible tasks within a Scrum Team, to obtain a better understanding of his role in Scrum.
The Product Owner can be defined as a “first action hero”. The tester joins the action at the very beginning, while mastering the product’s Backlog. As he knows the entire application and understands the user’s role and the value added with every functionality, he can take care of the quality, testability and usability of a functionality at the stage of the Product Owner’s verification of requirements.
The tester’s knowledge at this stage can help to avoid unnecessary work, which could result in the Product Owner not delivering the value expected. Effects? The whole team saves time on developing the functionality that would be impractical, a copy of previously implemented solutions or useless in the delivered system. We save time, as instead of rectifying incorrectly planned solutions, we focus on delivering expected results and high quality products.
Is estimation only for developers? It is a common opinion among Agile teams, I must admit. From my own experience I can say that mastering the product Backlog and eliminating unnecessary work plays a key role in the estimation of tasks by the Scrum Team.
It often turns out that Development Teams encounter issues in terms of the time needed to test the implemented solution. But the development process is not finished after successful implementation. This is why, when estimating, we should take post-implementation activities into consideration. During planning it is the tester’s role to foresee all testing-related tasks adequately earlier on. Thanks to proper estimation, the tester will not be overwhelmed by the number of tasks; additionally, a lack of time for testing within a Sprint should never be the case.
Let’s bear in mind that, in a Scrum Team, the whole team is responsible for potential failures, so all team members should try to avoid the aforementioned situations. Proper estimation will help to stipulate the team’s efficiency and improve the process of declaring realistic Increments.
Creating the Definition of Ready and Definition of Done
Each Scrum Team should prepare two documents defining whether the product is ready: Definition of Ready (DoR) and Definition of Done (DoD).
DoR defines when a particular Backlog element can be included in a Sprint, meaning whether it is prepared in such a way as to ascertain its understanding, implementation and delivery – the tester’s knowledge in this matter is vital and necessary.
At this stage, a tester should especially take care that each Backlog element is understandable and testable. The tester’s knowledge and expertise help to ensure that this point is fulfilled for every single Backlog element while mastering the product Backlog.
The Definition of Done (DoD) defines whether the development process for a particular element is finished and whether the functionality is completed. It is important to ascertain that this document contains a point about test coverage to confirm that every functionality works. However, in my view the type of test should not be specified, to avoid a situation in which some Backlog elements were not finished due to the lack of the possibility of running specific types of tests. It results from the fact that the Definition of Done pertains to every created element, but the kind of test and how detailed they are can differ, depending on multiple factors.
Thanks to understanding the rules which define the functioning of Scrum Teams and the fact that their members, regardless of roles and competences, can have a real impact on the value and quality of the product, we gain a new perspective of the tester’s role in the delivery process.
In the text – which hopefully is only the first out of many related to the tester’s role in Scrum – I was trying to show how important the tester’s input is – and not only at the stage of running tests after implementation. Looking at it from a wider perspective, we can see that searching for bugs in functionalities is not the tester’s sole task.
The tester also contributes to the proper planning of the whole team’s work, so that it is possible to deliver the best possible value altogether. I hope that many junior testers, who are looking for an answer as to how to improve both their work and the work of the Development Team, will find this article useful.