The software tester

01 Mar 2021

For some software engineers the role of software tester, and quality assurance are roles that should go by the wayside. Most of these software engineers are following the agile methodology to software development, where the roles are often seen as blurred, or non-existent.

I am writing this article as I recently was interviewing an Engineering Team lead, who stated he saw the role software tester as a role to still hire for. Unfortunately I never did ask question how he saw the role fitting within a team, to my loss. It did raise for me the concept of role of software tester and how they can fit within an agile software team (agile is used loosely here).

I want to make it clear my opinion early on was that with agile software testers role was more or less gone, I worked with a software tester at one company, unfortunately the role was the old waterfall approach, you do some work, test it as best you can and the figurative over the fence to the tester. Unfortunately having a single software tester in a team meant that there was a backlog of stories/tasks to test, which were blocked. This of course made me think that the role shouldn’t exist, it didn’t fit agile.

Then I joined another company, much larger that would never hire any sort of software tester, the role of testing fell squarely on the team to handle, and no one had the specailised title of software tester. Which is quite strange, there were specialists in agile, devops, infrastructure etc, but the role of software tester was just something you didn’t discuss. My time there saw many errors, which made me reevaluate my opinion on software tester role.

Software developers are notoriously bad at testing, we think some automated test (if we bother), is enough to spot issues. This can be the case some time, but others it’s not enough, we usually only think about testing when we are writing code, or afterwards. Manual testing is usually not something we do unless a Product owner sits down with us and goes through the story/task with us (and yes I’ve been in this situation).

I am still of the opinion that the traditional software tester role is gone, they cannot be a blocking agent within the flow of work, but they should become an enabler, a multiplier. The only way to do that is to get software testers who understand software development. What this means is they can also work on stories/tasks but they are acutely aware of how changes affect software and what should be tested;

1. During story/task creation they’ll enforce strategies that should be followed for testing
2. They’ll spot potential hazards early on, and see point 1.
3. They are a coach, their role is not software testing, but rather coaching others on testing.

This is not a complete list, but I think point 3 is the strongest point there. They coach software developers on testing practices both automated, manual and how to think differently. This enables other developers to take an approach not taken previously, this also makes them a multiplier, they dont need to be the ones just testing, software developers will do this.

Of course the issue now is

1. Getting people to understand the need again and;
2. Finding the right software testers who can fulfill this role.

It’s good to know my line of thinking is not quite that unique in this, so hope is there that these people are out there, as written in “Agile Testing: A Practical Guide for Testers and Agile Teams” by Lisa Crispin and Janet Gregory.