Tester in an agile team: a necessity or dispensable?
Let’s imagine it’s the year 2025 and we peek inside an average IT company to take a look at the software development teams working there: what are the chances that there will still be a person who is a tester in each of these teams? Some of you will say: “of course they’ll be gone, everybody will be a developer by then”, while some will hope that the role of the tester will still exist. What would that role look like, then?
If we go back to the current day and age, we can already see a trend that’s been going on in a lot of companies that will give us a peak in a not so pleasant future.
For now, many companies focus on test automation as a way to go forward with testing. That’s cool, getting feedback earlier and more often. But how are they trying to get their test automation suite up and running? They tell their current testers to learn about programming. These testers try their best, because often the consequence is losing their jobs if they don’t. However, being a developer is a specialism on its own that requires years of training!
What is the end result of turning your testers into developers for test automation only? Very crappy developers. Very crappy code. And most likely, not the good feedback cycle you were looking for. You will also lose the strengths of these testers in the process. If they are now only busy with code (and taking a longer time, because it’s new to them), they have no time doing all the other things testers do. We don’t expect a developer to know all the programming languages needed for the team, but we do expect testers to be able to do everything that one can wish for? That’s simply not feasible!
If you think that all testers do is ‘verify if requirement X works’, then you’re mistaken. I don’t blame you. When testing is not your profession, it’s not strange that you don’t know a lot about it. The testing profession is also much harder to put into a box compared to the programming profession (and that’s what people like to do, putting things into boxes. It makes the world structured and easier to comprehend). A programmer creates something tangible. Even though there are probably a lot of misconceptions about what programmers do, in the end they can always point towards a line of code and say ‘I made this’.
For testers, this is often a lot harder to do. We are in service of quality, but we don’t directly create it. We seek useful information in a variety of different ways, but it’s not as tangible as a line of code.
Can you see where I’m going here? I’m trying to see the point of view of people who work with testers, but who don’t exactly know what testers really do. It’s because of this unintentional ignorance that the testing profession is widely misunderstood these days. Who are these people that misunderstand the testing role? They can be other team members, such as developers, product owners, scrum masters, but they can also be project managers, other types of managers, people who decide who gets hired. And sadly, also other testers (yep, sometimes even testers don’t really know what testers can do).
If we go back to the box metaphor, the trend is towards the box: ‘testers should spend a lot of their time on test automation and that it their main task’ (Please, prove me wrong and give me an example of a job description for agile tester that does not have this as main element). Just like that, testing is made easy; it’s broken down into a single task. Easy to understand for everyone involved.
It makes a lot of testers sad, though. We can and should do so much more than automating stuff! I can highly recommend you read this list, but the important points I want to stress are:
- Collaborating with team members
- Gathering information
- Asking questions
- Discovering broken assumptions
- Analyse bugs
- Learning about the product
In my opinion, the most important one is ‘gathering information’ (that is the core of testing) and most other tasks are supporting that general mission. Test automation will definitely help find a certain type of information, but focusing only on that is too one-sided.
Isn’t there an alternative? Why not go on the journey to make the whole team more quality minded? When the developers help with automation for testing you’ll probably end up with a more sustainable solution. I see a big role for testers here. We should transition into a hard-core support role. We will still do testing, but we will spend a lot of our time educating others. We will get everybody quality infected. This is what the industry needs: the human aspect. We need to wake up and realise our problems are not going to be solved with a technical approach only. People need to learn to work together, to speak up when they think something can be solved differently, to figure out the which test case is worth automating in the first place.
When 2025 finally rolls around, I still hope to see testers. I just hope that their roles are more broad, not necessarily fitting into a simple box. And quite possibly, there will be mature teams, who’ve had the help of a tester and now can do all the testing tasks on their own. For now, though, testers have work to do. We have to reinvent ourselves and educate others about what testing is. We need to reshape how part of the IT industry views us. Are you up for that challenge?