The Role of Testing: Thoughts from KWST5

The topic for the fifth annual Kiwi Workshop on Software Testing (KWST5), which took place last week, was 'defining and defending the role of testing'. It was a very interesting and invigorating two days, rich with discussion about what the role of testing is, what it means to fulfil it, whether it needs defending, and how we might do so.

One of the main things that I took away from the two days was a distinction between two types of role - throughout the conference, we called them "big R" roles and "small r" roles, and I'll re-use those terms here.

A 'big R' role is a heuristic that guides and informs the tasks that a person will be expected to pick up. When you occupy a 'big R' role, there is an implicit expectation that you possess a level of competence, initiative and accountability that allow you to fulfil that role successfully.

In contrast, a 'small r' role is more of a temporary commitment to a task or set of tasks that fall outside of the 'big R' role that the person might occupy. As a necessary compromise, anyone fulfilling a 'small r' role can be expected to possess a lesser level of competence, initiative and accountability when it comes to fulfilling that role.

I find this to be a useful model for thinking about the expectations that we have when we, or others, are performing certain tasks. Indeed, becoming conscious of the role, or roles, that you occupy - whether 'big R' or 'small r' - and the associated expectations, seems to me to be a very simple way of beginning to understand your context.

In teams, it might be useful to workshop the roles that need to be fulfilled in order to deliver a project successfully. This could include consideration of what tasks and responsibilities are beholden to which role, and which team members will be fulfilling each role - again, whether 'big R' or 'small r' - in a given situation.

Such a workshop will likely accept that some tasks may be outside of all 'big R' roles, and thus will require team members to temporarily accept 'small r' roles to get them done. It may also note that some tasks are included in every 'big R' role, thus establishing some core principles or responsibilities by which the team will operate.

An example of the former could be the task of chairing a weekly team meeting. It's no one person's responsibility, but instead someone will temporarily commit to it each week. For the latter, we might expect that all members of a team will keep communal office spaces clean and tidy. Every one has an ongoing, implicit expectation to complete this task.

The model has value in an agile context too, where often it is suggested that there are no distinct roles. Using the shorthand we developed during KWST, this might be the same as saying that in an agile team, everyone simply holds multiple 'small r' roles, picking up on a temporary basis whichever task most requires attention.

In such a situation, with a larger reliance on people fulfilling 'small r' roles, the team necessarily risks decreasing the level of competence, initiative and accountability that is available to fulfil each of the roles.

As such, it is my view that a successful agile team would still have 'big R' roles. An agile team is not a team without specialists, it's a team where specialists are able to cooperate and collaborate more effectively, and there is a shared responsibility for the overall delivery.

In such a team, you may still find someone who occupies a 'big R' role as a tester. The boundaries of that role will likely just be a little more fluid than a testing role in a more rigid environment, and other team members may more regularly occupy 'small r' testing roles and complete certain testing tasks.

This brings us to what was in many ways the crux of the topic for KWST5 - which is the perceived threat to the role of the tester in agile contexts. Some agilists will argue that there is no room for specialist roles in an agile team, with many agile teams either forgoing specialist testers or pressuring their testers to become programmers-that-test.

My belief, reinforced by the discussion over two days at KWST, is that this is a naive view that risks sacrificing the genuine expertise that specialists bring in pursuit of an impossible ideal. While people can fulfil multiple 'small r' roles, it is very difficult, perhaps impossible, for one person to fulfil multiple 'big R' roles.

A 'big R' role requires a commitment not just to competence, but to increasing competence. It requires you not just to take the initiative in the present, but to anticipate problems in the future. It means you are accountable for what happens, but also expected to learn from those experiences to shape the future.

This is a heavy load. Successfully occupying a 'big R' role in any discipline - be it tester, developer, business analyst, tightrope walker, astronaut, anything! - is a demanding occupation. It requires a personal commitment of great amounts of time, energy and motivation to the role.

In this sense, a 'big R' role is rarely project specific. It is something which cannot be forced upon you, instead you must accept and embrace it. And for this reason, it is also impossible to simply ask members of an agile team to fulfil a 'big R' role as and when they might be required to do so. It usually requires pre-existing commitment.

So, unless we are au fait with a reduced level of quality, the product of having tasks completed exclusively by people occupying 'small r' roles, there remains a place in effective agile teams for specialists. These 'big R' roles, occupied by people who are devoted to their craft, but who are also open to temporarily accepting other 'small r' roles as required.

In short, my two days at KWST5 confirmed that the role of testing may be under threat, but it is well defended. I shared passionate debate and discussion with 18 people who all devote themselves to the occupation of 'big R' testing roles, who have made a commitment to being excellent testers, and who, just by getting together and talking about it, embody the role of testing.

The thoughts and ideas in this post are crystallised from the discussion at KWST5. It would be impossible to cite each reference to a singular source, so instead the credit and my gratitude go to all attendees of the workshop, listed here: Aaron Hodder, Andy Harwood, Chris Priest, David Robinson, James Bach, James Hailstone, John Lockhart, Joshua Raine, Katrina Clokie, Mark Boyt, Mike Talks, Oliver Erlewein, Rachel Carson, Rich Robinson, Sarah Burgess, Scott Griffiths, Sean Cresswell, Till Neunast.