I used to think that as a software tester, ‘if you’re doing your job well, then no one notices’. This sort of thinking was something I was perpetuating by misunderstanding my role as (merely) someone who performs test execution. I could see the benefit of the work I was doing and assumed that because no one else seemed really interested, they didn’t care.
From my experience, there is a tendency for testers to be thought of as second-class dev-team citizens, if not overtly then subconsciously. A developers job is perhaps easier to visualise than that of a tester. I’m not saying their job is easier, but for some reason a coder implementing programming algorithms by writing code seems easier to picture than a tester implementing testing algorithms by… ‘you guys just click on stuff to make sure it works, right?’.
I spent a lot of time arguing for recognition of testers and questioning why other members of the dev team seemed not to understand how important testing was. It was frustrating to me. It seemed like more often than not, when people took notice it was because something had gone pear-shaped because it was my fault (I’m the quality guy, right?).
It slowly dawned on me that it wasn’t because they weren’t interested, but because the way I was conveying the how, what and why of testing was not compelling. My colleagues knew development. They understood development, but their experience with software testing was limited. It’s not that they didn’t value the test team, but the way I was reporting my testing wasn’t as relevant to them because it was more or less a binary ‘Yes I have found problems’ or ‘no I haven’t’. This had a dangerous side effect of making me a defacto deployment gatekeeper.
They valued the ‘yes’ or ‘no’ a great deal, but because that’s all I was providing, and because that was their experience with testing, that’s all that was expected. I was thinking hard about testing and how the product might break and what else might go wrong, but I wasn’t really focused on how to get that across to the people that mattered. They assumed that when I said I was done, I knew enough to know that was true. To be honest, at that point, I didn’t know enough to argue otherwise.
As my experience in testing grew, I realised that test execution is a small (but of course important) facet of a tester’s role. I began to see the testers role as multifaceted and I became part devils advocate, part psychopomp and possibly large amounts of the damned from various circles of Dante’s inferno :). I pushed to be included earlier in the project lifecycle. I asked questions, made suggestions, asked for documentation and information and made sure the people I was working with were across the thinking I was doing about risk and risk mitigation. I started talking in terms of how the testing we were doing was covering the risks we’d raised (and sometimes how it wasn’t). I didn’t always go the most diplomatic way about it, but gradually things began to change for the better.
The role of a tester to me now is to really be a central information hub, and a representative for those who may not have a voice (such as the end user). Reporting the test effort should be a matter of knowing who your audience is (or more broadly, who matters) and what matters to them. The development group I work with now have come to expect assessments of risk, analysis of proposed solutions – the thought behind the effort is as important as the effort itself.
I suspect that my early experiences are not uncommon. I have heard and read many accounts of testers feeling undervalued and misunderstood, being blamed for errors that go into production, being the gatekeeper for the decision to deploy. I don’t think testing is nearly as understood as a profession as coding is and it’s something I’d like to change.
I think the onus is on the software tester to be proactive in promoting their effort in such a way that it adds value to those that matter; so that the people they are supporting understand exactly what the tester’s role is. I think there is a need for education both of non-testers, to show them the value of software testing, as well as education of software testers so they are able to convey a compelling story of what their testing is and does and why it matters.
My situation is of course going to differ from other testing shops out there, both in the style of work and the relationship with developers in the development or project group. There may be an element of ‘picking your battles’, or making change in small increments over time. Testers might face extreme reluctance or hostility to change. I think at that point it becomes a matter of the tester being clear on the sort of behaviour they are willing to commit/adhere to, and those that they will not. More on that soon.