testing concerns

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.

2 thoughts on “testing concerns

  1. Thank you Rachel. I’ve seen the same thing, particularly with the new front end vs. back-end architectures where the tester would need to know how to use developer tools or fiddle or some other tool to figure out if the problem was front-end or back. The solution is usually just teaching the debugging tools — but I’ve also had the “it is not my job to teach you” response. I find that response unsatisfying. One of the things I’ve had some success with over the past few years is reframing testing as “providing information (including usability)” instead of “finding bugs.”

    Looking at it the other way, I’ve also been on a project where we found problems that were never specified. The lead dev was offended when we said “found a bug!” and eventually explained “sometimes when you say that, there are executives in the team room.” We started to say “found an anomaly that may require a change” instead of “fix”, and everyone was happy. If a change to my language is needed for the team to jell, I’m likely willing to change my speaking.

    Thanks again for the post! Good stuff.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.