You don’t “get it” until you see it

I was involved in a Twitter conversation recently about the value of testers in a software delivery team and the kinds of skills we expect of testers. It got me thinking about how I learned to appreciate and value skills other than my own.

Do testers need to be able to code to be valuable? @lisacrispin says no. But they do need technical awareness, a common language. #Agile2015

— Em Campbell-Pretty (@PrettyAgile) August 4, 2015

I’m a software developer by background so, of course, I believed that the world revolved around coding and that mine was the most important rôle (an example of egocentric bias). I was working in loosely-structured environments where I hardly ever encountered rôles such as “business analyst” or “tester”. When I later worked with people in those rôles, my initial perception was that their skills and contribution were secondary to my own (after all, I’d managed without them thus far, hadn’t I?).

Until you see someone performing a rôle really well, it’s tempting to dismiss it as superfluous. I’ve seen organisations where testers are viewed as an overhead; I’ve been in companies where scrum masters (or iteration managers) are viewed as unnecessary; I’ve seen business analysts viewed as irrelevant. As soon as the owner of the budget looks for cost savings, they start crossing off the rôles they don’t understand or value.

@Steve_Hayes @lisacrispin coding to a non-coder seems hard and magical; testing to a non-tester seems easy. Same with BA, SM.

— Andy Kelk (@andykelk) August 5, 2015

The thing about coding is that, to an outsider, it’s opaque and it looks hard. Someone who hasn’t coded before has a hard time imagining themselves doing it. Therefore they accept that it’s something a specialist should do.

When a skill is less technical (such as exploratory testing, business analysis or coaching a team), there’s a tendency for an observer to belittle it. They imagine testing is just sitting and clicking a mouse all day; or that business analysis is just writing up other people’s ideas; or that a scrum master is just a glorified project admin. And then the questions start: “Couldn’t we just combine them all into one?” or “Do we even need that rôle?”.

With testing specifically the assumption is that by automating tests we can just get rid of all the testers. If you’ve worked with a good tester, I hope that sentence makes your toes curl. In a world with plentiful automated tests the nature of the work that a tester performs changes but a tester is hugely valuable to successful delivery.

@Steve_Hayes @lisacrispin once people work with a good tester (BA, SM, etc) then they get the value and wonder how they ever managed before.

— Andy Kelk (@andykelk) August 5, 2015

If you’ve not been lucky enough to see good testers (or BAs, or Scrum Masters) in action, seek them out. Once you see it, you’ll “get it”.

Archives