I was talking with a newer tester the other day, and the impression that I got was that there was a lot of insecurity around their testing. They felt like they didn’t have a right to say that they found a bug unless they came armed with bulletproof facts and basically a root cause analysis. They don’t feel like they have a right to an opinion, because they are still new to this. They feel like their bugs are more of a nuisance than a help. To all this, I say, “hogwash”. (/gets up on soapbox)
Testers have every right to raise concerns with the product, even if their concern is not directly related to a requirement or an acceptance criteria. Testers may not know the code, but they do become familiar enough with the product to understand how it should behave, consistent with itself and with other applications (e.g., making your shopping cart icon consistent with shopping carts on other applications rather than trying to be clever). Testers also have a sense for when a flow is too cumbersome, even if it’s “as designed”. Disregarding the opinions of a tester because they are new to testing or new to a team is something that puts a team at risk. My concerns are sometimes addressed as being too hard to change or not what the product owner wants to do, but that doesn’t mean that my concerns are invalid. Testers have a duty to advocate for the user (while recognizing that we are not the user).
In my first law job (goodness, that was ages ago), I went to a partner with a question. His response was, “What have you done to figure out the answer for yourself?” I went away, somewhat chastened, but I made sure that I had a list of things I had done the next time I went to him. That phrase has stuck with me through the years and has influenced my testing. I ask questions all the time, but I also seek the answers for myself through searching our backlog or closed stories, checking oracles, and trying other paths. However, I do not read code very well, so I don’t often engage in finding the source of the bug. And there are times when I can’t find steps to reproduce a bug, but something had gone very wrong. When that happens, I apologize to my devs and attach as much info as I can, while acknowledging that I know very little. If I have a gut feeling, I will state it but make sure it’s known that it has no evidence. I try to limit the times I do that, but sometimes it can’t be helped. At any rate, the lesson that law partner gave me in my second week of practice made me a better lawyer and makes me a better tester. The tricky part is knowing when I’m just spinning my wheels. And it can really suck to do that work, when I know that I could just ask. It’s worth it though.
The last concern worries me, about bugs being more of a nuisance than a help. This one, I think, requires setting the dev(s) straight about the necessity of testing, and the goal that we are trying to achieve. It may also require a change of the tester in how they are talking about testing. We all want to produce something wonderful and fun to use. If devs are treating the bugs testers find as problematic, even if they’re just joking around when sounding exasperated, that’s not okay.
If you are feeling like this tester, speak up! You’re not alone, and the team really does want good code, not just finished code. Be bold and assertive. You are valuable, and what you do matters.