Developing the QA Mindset: Distance From The Code

Hey folks! I’m back again with another installment of the QA mindset series. Today I wanted to talk about a key factor for stepping into the QA mindset: distance from the code.

You may be wondering, why is distance from the code so fundamental to the QA mindset? Speaking for myself, I was a QA / SDET for 7+ years. I am very capable of testing things well. However, the difference between when I’m testing my own code versus when I’m testing someone else’s code is night and day. If I just spent a day hammering on a problem, and I finally get it to work, then I often only spend my time on narrow acceptance testing. If I’m coming in fresh to a change I’ve never seen before, I’m much more capable of approaching the task with the curiosity necessary for effective exploratory testing.

So what accounts for this difference? I attribute this to a form of attentional bias. Attentional bias is the tendency to focus on a particular stimulus that grabs our attention or is somehow emotionally charged, at the expense of missing other, less gripping information. When we as developers have been hard at work writing code, we are more likely to focus on the satisfaction of finishing a difficult feature than the work of ferreting out bugs hidden in edge cases. This inhibits our ability to step into the QA mindset, and it’s why I always advocate that someone other than the code owner should test a change during the pull request stage. This process is not without its cost. The reviewer needs to fully context switch to review mode, often stashing their own in-flight changes to load up a feature branch in their development environment. However, the cost of not doing so is a test run with blinders on.

This is also why it’s so important to have someone play the role of tester in the planning phase. As I described in my last post, the tester is one of the three amigos of planning, and is tasked with thinking about edge cases. Their attention is intentionally drawn away from how the feature should work as they are encouraged to focus on how the feature will break. This can be a difficult role to step into at first, so let’s take a moment to talk about frameworks for planning and writing work tickets that can make this easier. I’m a proponent of the INVEST framework, which states a ticket should be:

• Independent

• Negotiable

• Valuable

• Estimable

• Small

• Testable

I like to apply this framework to any ticket that gets reviewed in refinement or team planning. For teams new to INVEST, I would even suggest explicitly asking these questions for each ticket. “Is it Independent? Is it Negotiable? Is it Valuable? …” As you build this muscle, discussions about story writing will naturally occur in planning. Whether you’re an expert in this process or giving it a try for the first time, you’ll likely find that asking whether a ticket is testable inevitably leads to questions of how you will test it and what you will test. This works wonders for improving feature quality. When we create space for these discussions and normalize this mode of thinking, we begin to expand our attention beyond the narrow criteria of the feature. We step into the QA mindset and see the broader space this work occupies in the whole system.

That’s it for this post. Next time we’ll pick up again with a discussion of carving out time for testing!