Hierarchy in an agile team
The question about a tester’s value as a member of an agile 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 agile 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.
Team members: 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 software 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.
Elevate Your Application Development
Our tailored Application Development services meet your unique business needs. Consult with Marek Czachorowski, Head of Data and AI Solutions, for expert guidance.
Schedule a meetingRoles and responsibilities in Scrum – common myths about tester’s role
“We don’t need testers in an agile team”
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 agile 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. In agile development, 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.
“Agile tester only performs automated tests”
Another, in my view harmful, myth is that there is no place in Scrum for tests other than automated tests. 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.
In the software development process, 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 agile 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 agile team will be better and more efficient as a result.
Agile tester’s tasks within a Scrum Team
Mastering the Product Backlog
Many people wonder how a tester engages in team activities in Agile methodologies. Let’s have a look at a tester’s possible tasks within a Scrum Team, to obtain a better understanding of his role in an agile team, particularly in Scrum.
In Agile methodology, the list of everything that needs to be done to improve the product is included in a Product Backlog. The Backlog consists of user stories – the smallest units of work in the software development process that explain in a simple way what needs to be done and what is the goal. User stories are written from the end-user point of view.Example of a user story: As a (role), I need (goal), so that (explanation). While mastering the product’s Backlog, the Product Owner can be defined as a “first action hero”. The agile tester joins the action at the very beginning.
As the tester 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 the stage of mastering the Backlog can help to avoid unnecessary work, which could result in the Product Owner not delivering the value expected. Effects? The whole agile 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.
Read more: Get to know Agile nearshore software development
Estimation
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 for software testing.But the software 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).
Definition of Ready
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.
Definition of Done
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.
When do we involve tester in Scrum?
This is the last question while exploring the tester’s role in a Scrum Project. And there is only one correct answer – always. If you expect a high-quality solution that would meet users’ expectations, you should include testers in your team. Experienced software testers can take care of a wide range of testing services such as test automation, regression testing, exploratory testing etc.
Read more: What is Regression Testing
Agile tester – summary
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 agile tester’s role in the delivery process.
In the text – which hopefully is only the first out of many related to the agile tester’s role – 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 agile 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.
Consult your project directly with a specialist
Book a meeting
He has been working in Inetum for over 4 years now as a software tester. In private life, he is an enthusiast of cinema and beer revolution. Believes that testing is an ability of asking adequate questions and preventing bugs is more important than searching for them.