Tester in an agile team: a necessity or dispensable?

Maaike Brinkhof

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?

Comments (6)

  1. Lisa Crispin - Reply

    February 8, 2017 at 10:27 pm

    I heard Melissa Eaden say on the Let's Talk About Tests Baby podcast that programmers are more likely to go away than testers - code might all be written by AI and machines, but it is unlikely that software can be delivered without human testers getting involved. I think there is some truth to that! Though I think we will need all the human skills and competencies we have now, and more. I like the blurring lines, I love helping my team become obsessed about testing and quality!

    • Maaike Brinkhof - Reply

      February 9, 2017 at 10:07 am

      Given that there are so many horribly old and outdated systems in the world still, even programmers will have work for a long time!
      But yeah, we need more focus on the human skills. It's going to be my mission to speak more at developer conferences about testing, hope to get a broader audience that way. Any particular tips you have to get people understand testing better?

  2. Lisi Hocke - Reply

    February 9, 2017 at 12:59 am

    "Please, prove me wrong and give me an example of a job description for agile tester that does not have this as main element" Challenge accepted 🙂 https://flixbus-cand.talent-soft.com/job/job-software-tester-m-f_260.aspx (any feedback appreciated) Besides that, I'm curious how a development team will actually look like in 2025. But I'm definitely going to be around and contribute my part to building great products in some way or other.

    • Maaike Brinkhof - Reply

      February 9, 2017 at 10:05 am

      Cool that you accepted my challenge! That job opening indeed looks better formulated than most others I've seen!

  3. Alexander Romanov - Reply

    February 9, 2017 at 12:16 pm

    In my opinion the main point why managers consider testing a fairly simple skill and push testers to learn automation - because in many companies testers are separate from the other team and completely unable to influence on the product. They (testers) just run regression day by day for hours.
    Maybe the solution to such IT companies is to show what set of testers can actually do in order to improve quality in various ways and to give test department more power to influence.

    • Maaike Brinkhof - Reply

      February 9, 2017 at 2:55 pm

      Good point, Alexander. If the testers are still in another team, you have a different problem entirely.

Add a Comment