I love software testing. And learning. And teaching… I actually spent a good chunk of time pursuing a degree in education. Eventually I stumbled into the world of software engineering, and now I’m a Software Quality Assurance Analyst at APAX Software.
With all that in mind, it only makes sense that one of my favorite things about working at APAX is the opportunity to pair test with our software engineers. These can be teachable moments for both parties; I get to learn how features should work and the thought process behind building the darn thing. In exchange, it’s only fair for the engineer to learn how to think of their work through a tester's mind.
Once I know how the feature should work, I start throwing darts—at the feature, NOT the engineer (despite what they might tell you!). These metaphorical darts stem from skepticism and curiosity and usually take the form of questions that reveal gaps in the requirements or challenge the silent assumptions that no one raised in the discovery phase. I digress.
Luckily for me, I get to work with some of the smartest people I know, where continuous improvement is fostered and valued by the entire team. Courtesy of APAX, I recently attended the QA or the Highway conference in Columbus, OH. I mostly found myself in lectures focused on AI tooling and healthy skepticism. In my mind, skepticism is required to be a good tester, so it was extremely validating to go to multiple lectures where its importance was emphasized.
Even though I hate public speaking, this experience inspired me to share some ways that everyone on our team could think more like testers, improving the quality of our work.
Quality is the foundation of everything we do here at APAX. Everyone, from our designers to project managers to engineers, contributes to whether or not the final product is usable, functional, and cohesive.
If you write requirements, you influence quality. If you design flows, you influence quality. If you write code, yuuup, you definitely influence quality. Thinking like a tester gives you another lens for spotting gaps before they become costly (and often embarrassing) problems.
There are a lot of definitions out there for testing. Here’s my personal favorite, which Satisfice, Inc. coined:
“Testing is evaluating a product by learning about it through exploration and experimentation, including to some degree: questioning, study, modeling, observation, inference, etc.)”.
Testing is not mindless. I think it’s easy for people to imagine testing as some oaf mindlessly clicking buttons, checking off acceptance criteria like a grocery list. On the contrary, testing is a thoughtful, deliberate, and exploratory process.
Some good things can happen when you approach your work with curiosity and skepticism. You can anticipate and prevent problems before they occur. You can also prevent confirmation bias.
Anticipating and preventing issues before they occur is extremely valuable, especially when working in a fast-paced environment where you need to deliver quickly.
Paranoid? Maybe. Effective? For sure. This doesn’t mean you’re rooting for failure. I see it as detective work, where I must unmask an unsuspecting criminal. A skeptical mindset helps you dig deeper, avoid confirmation bias, and stumble into those weird little edge cases that real users inevitably find.
Features don’t exist in a vacuum - they’re part of a larger ecosystem. Testing with the bigger picture in mind helps prevent regressions and can reveal inconsistencies in design or behavior.
Requirements are rarely perfect. Asking questions helps you learn quickly, uncover hidden assumptions, and shine a light on business logic gaps that must be addressed. It also helps you better understand the why behind what’s being built. When you know the why, you can ask better questions, too.
It’s important to understand and consider your users as you’re testing. Your users aren’t robots. They’re humans with goals, frustrations, and little patience for clunky software. Put yourself in their shoes: Is this feature intuitive? Helpful? Usable? Does it solve their problem, or does it just look good in a demo?
Testing is exploratory by nature. That means you get to be critical, creative, and intuitive. You don’t have to be limited by the list of tests you plan to execute. You can explore beyond those bounds.
But with freedom comes responsibility. If you can’t explain why you’re performing a specific test, you probably shouldn’t be doing it.
Everyone is responsible for quality. Adopting a tester’s mindset just helps us live up to that responsibility. It’s valuable to adopt this mindset as we (humans, if you were wondering) increasingly use and rely on AI to assist us with tasks. When submitting a prompt to an agent, do you trust the output completely, or are you skeptical? Hopefully the latter.
This mindset isn’t limited to testers. Everyone can adopt it, contributing to a culture that values quality while working in a fast-paced environment.
