In today’s world in which agile methods are no longer new and obscure but rather commonplace in more and more companies, many testers among us wonder what will happen to the traditional career ladder.
Many of us have always viewed Test Management as a goal in our career, but with the advent of agile methods, that goal has become slightly blurred. According to Scrum methodology, all the team members have a shared responsibility for the quality and the role that most of us will fill is the team member role.
This begs the questions ‘Is the test leader really needed in the agile world?’ And if so, what does it mean to be test leader in an agile context?
In this article you will learn why the test leader is as important in agile teams as he or she was before, as the tasks to be done are there no matter what we call the role.
In a team, who leads test work, if at all?
Let’s imagine a company in which we have only one Scrum team. We develop a product over multiple sprints and our team has a Product Owner, a Scrum Master and team members. The Product Owner explains what the product will do and our Scrum Master ensures that the team members follow the established approach. The team selects their individual tasks from the Scrum board and do what we have decided to do in the sprint.
This approach already interprets the concept of team members and their task a little looser than what Scrum prescribes.
Normally, some team members will do development work and some do test work, just because we simply are better in one or the other. As testers we read what our sticky note says and begin to verify that the added functionality works as intended. Once that is done, we will move the sticky note to the next column on the board. The whole process seems to have worked quite splendidly, even though we did not have a test leader. Or did we? Did we have a test leader without even thinking about it?
What have we testers done? Did we select a sticky note from the Scrum board, completely at random and test it without a second thought? Probably not! Even when we decide on the content of the sprint, we would have given thought to how long it would take to test in the current sprint, how much time our regression tests will take, how tests will be conducted in the smartest and most efficient way.
It is highly likely that we figured out the order in which we should take on the tasks on the board together, so that we meet both the developers’ and the testers’ needs. It is also highly likely that we as testers decided on the test strategy and have reported the results at the daily Scrum meetings by moving the sticky notes on the board. No matter how we look at it, we testers have taken on tasks that normally are assigned to a test leader. At the very least this can be seen as us planning our own work as a tester.
If our team is working over many successive sprints we as testers are expected to create a test strategy that manages the amount of regression testing that occurs as well as the emerging product. So essentially, we also carry all the duties that a test manager normally carries out when are in a moe formal, less Agile team.
Bigger product / more complexity? You need parallel teams!
So far we’ve talked about having a single Scrum team, but what if our company has many parallel teams working on the same product – what’s it like then? Can’t we go along without a formal test leader, just as we did when we had just one Scrum team? After all, each team has its task and has full responsibility for it! However, who is then responsible for the way everything is put together? How do we test and how do we ensure that all tests are up to the same level if we have no common test leader?
One of the test leader’s most important tasks in a traditional development project is to plan the test work and decide the test strategy that will apply to all test work. If we do not define the strategy for our work together there is a high probability that everyone will spend time on creating strategies for their own parts. All too often these ‘individualized’ strategies can either overlap so that several persons are doing the same thing or even worse assume that ‘someone else’ is doing the job and thus leave the test areas and test types untested.
Not only is it simply inefficient to distribute planning over all the teams for the joint work, it also increases the risk that the product is not tested sufficiently. Subsequently, our work will benefit from someone with a designated responsibility for planning the joint test work and defining a common test strategy.
Having a test leader helps us to ensure product quality by having a strategic and well planned approach to test the work, even when we are working agile. The test leader is not to be placed in one of the teams, but should sit outside the teams to be able to focus on the overall approach.
Bonus – What happens when the teams are located in different parts of the world? Read ‘Working as a test leader in distributed test teams‘
Support in testing communication within and outside the team
The test leader is a resource for testers in individual teams. Not only does the test leader help testers to think about how to test his team’s tasks, he or she is also helpful when motivation is short. Test leaders also help to drive the continuous improvement efforts from a testing perspective as a whole.
We need someone who can assess which approach has worked better in one team, from a testing perspective, and who can lift it to become a norm for all the teams. It is hard to see beyond the team and see why someone else’s work is better than your own. How do we copy something that worked well in a team to another? How do we learn and find new approaches that can give us even more effective testing techniques?
A very good solution is to to conduct a retrospective session with the testers from all teams. The purpose of the retrospective is to identify pros and cons with the current way of handling things in order to improve the process.
In larger Scrum projects, the principle “Scrum of Scrums” is usually implemented. At regular meetings representatives from each team meet to focus on overlapping activities and integration issues. The same principle can be applied to testing to create a “test of tests” where test issues are under focus. As a test leader in an agile world, it is your responsibility to ensure that this happens. The Scrum Master could do it, but often they do not have the testing-knowledge needed to bring this improvement to its “next step”.
The test leader will also meet other stakeholders such as the client, the IT manager or whoever is responsible for the money in your organization. Probably no single team is responsible for this, but it is a joint initiative and needs to be managed as such. However, it could also be the end-users that plan and conduct demos and user testing. Each team’s testers can not run to the same people and ask for help, but obviously we need to coordinate it to be effective. Again, we say that the Scrum Master usually does not have the testing-knowledge that is needed to explain the need or to be able to analyze the results. In any project there is always someone who needs to assume that role, and why should not there be a test leader?
Agile test leader? Of course!
Someone always takes on the role of test leader, even in agile context. We have seen this over and over. Someone distributes work between what is internal team work and what is common test work. Someone reports the results of testing. Someone puts up the strategy for test work and plans the order in which the work should be carried out. If we are to call that someone by a name, that name would be test leader. Test leaders have an obvious role to play regardless of the development methodology used and in short, test leaders are needed!
The next step
There are a number of other very helpful articles about Agile work in our blog –
- You can’t work Agile without automated testing
- Test Documentation in Agile Projects
- Agile testing is the emperor’s new clothes
Join 60,000+ Subscribers
For latest blogs, industry updates and exclusive tips.
*Your email is safe with us, we also hate spam