Developing the QA Mindset
Welcome folks! To kick off this Substack I wanted to dig into some practical aspects of actually testing code, so I’m starting with a series about ✨The QA Mindset✨
As the name suggests, the QA mindset is a state of mind that a person needs to enter in order to effectively test, well, anything really. It prepares you to look at a piece of software objectively so that you can identify if it is ready to be sent to our users. Stepping into the QA mindset is a skill unto itself, and interviews for Quality Assurance Engineers typically try to ferret out how well a candidate can leverage this mode of thinking.
Over the next few posts I’ll try to capture how I approached the QA mindset during the 7+ years when manual testing was a core function of my work. However, before we get into the what and how of the matter, it’s important to understand when this mode of thinking should be applied. The obvious answer is that you need it when you are testing a piece of software. While this is objectively correct, if you’re waiting until a story is dev complete to leverage the QA mindset, then you are likely days if not weeks behind the curve. Discussions about testing should at least happen during story refinement, and for larger initiatives they should take place during product design.
To understand what those conversations look like, it’s useful to refer to Cucumber and the tenets of Behavior-Driven Development. Many of you may have used Cucumber as a testing tool, and if so you probably hated it. There’s a simple reason for that: Cucumber is not a testing tool. As its creators have said, Cucumber is the world’s most misunderstood collaboration tool. Viewed through that lens, it’s no surprise that The Cucumber Book spends a significant amount of time discussing the practice of testing. This portion in particular has always stuck with me:
Three Amigos
The best [test] scenarios are created when the three amigos come together, bringing three very different perspectives:
- The first amigo is a tester, who thinks about how to break things. The tester will typically come up with lots of scenarios, sometimes covering obscure edge cases and sometimes covering very important ones that no one else had thought of.
- The second amigo is a programmer, who thinks about how to make things. The programmer will typically add steps to scenarios, as he asks clarifying questions about what exactly should happen.
- The third amigo is the product owner, who cares about scope. When the tester thinks of scenarios that hit edge cases the product owner doesn’t care about, she can tell the team to drop that scenario out of scope altogether, or the group can decide to test it with unit tests only. When the programmer explains that implementing a particular scenario will be complicated, the product owner has the authority to help decide on alternatives or to drop it altogether.
You may be wondering, what does that mean for my company that has not hired dedicated Quality Assurance Engineers to be the first amigo? It’s important to remember that “tester” is not a job description. It’s a role that must be filled on a team. If we do not hire engineers who specialize in that role, then the folks we have must develop the skills necessary to play it themselves. That means it’s incumbent upon all of us to develop our QA mindset.
Over the next few posts, I’ll be digging into the three key factors for effectively entering and leveraging the QA mindset: distance from the code, ample time to explore, and curiosity. Stay tuned!