Over the last few years, my professional life was defined by a single event: failure. In technical support, engagement typically occurs when a system crashes, a feature malfunctions, or a user encounters difficulties.
My responsibilities centered on responding to these critical moments by investigating the underlying causes, formulating precise questions, retracing user actions, and facilitating communication between users and engineering teams.
Lately, however, I’ve been obsessed with the moments before that break. The quiet space where code is written, features are designed, and the potential for those puzzles is created. This shift in focus marks my intentional move into Quality Assurance. And the most significant change hasn't been learning a new tool or methodology; it’s been a shift in my own cognition. I’ve started Thinking in Tests.
What does that mean? It means moving from a reactive to a proactive curiosity. In support, I asked, "What happened?" Now, I constantly ask, "What could happen?" It’s taking that innate troubleshooting skill, the methodical process of elimination, the deep need to understand a system, and applying it upstream.
My background is an unexpected advantage. Years of listening to users describe problems in their own words have built a strong sense of user empathy. I consider not only the functionality of a login button but also how a fatigued user might misinterpret an error message. My direct experience with the consequences of unclear instructions or unexpected behaviors motivates me to proactively identify and address such ambiguities.
"Thinking in Tests" is the framework I use to structure my learning. It turns every application I interact with into a living case study.
Using a food delivery app: I don't just order lunch. I think, "What if I switch my payment method mid-order? What if my internet drops while confirming? What are the boundaries for the delivery address field?"
Reading a news article online: I notice how the page loads. "What happens if I click that banner ad before the main image renders? How does this site behave if I have a slow connection?"
Even encountering an actual bug: My old support brain kicks in to diagnose it, but my new QA brain immediately starts mapping it. "What test scenario could have uncovered this earlier? What assumption did we make that was proven wrong?"
This mindset is how I’m building a stronger QA foundation that goes beyond tools and checklists. It’s about:
Critical Thinking Over Checklists: Questioning every requirement. "Is this what the user truly needs? What isn't being said?"
Empathy as a Test Oracle: I use my understanding of human behavior to anticipate potential points of friction and confusion.
Systematic Exploration: I apply a structured thought process, such as considering possible inputs and outputs, even during informal exploration.
Clear Communication: Translating what I find into clear, actionable information, just as I once had to translate user reports into technical tickets.
I write this blog to solidify that learning. Writing forces me to slow down, to connect disparate ideas, and to reflect on how my understanding evolves. It turns fragmented "aha!" moments into coherent understanding. This space is my learning journal, meant to build consistency, clarity, and depth.
"Thinking in Tests" is not about having all the answers. It’s a practice. It’s about learning deliberately, questioning assumptions relentlessly, and seeking to improve not just software, but my own perspective, one test, and one thought, at a time.
If you're on a similar path, or if you've found ways to train your own professional mindset, I'd love to hear about it. How do you see the world differently through the lens of your role? Let's talk in the comments.
Comments
Post a Comment