I’ve written hundreds of test cases. But one of the most useful things I’ve done as a QA engineer this year started before testing.
There’s a question at the core of QA work: Does this match the requirement? It’s a good question. It’s the one I was trained to ask. It’s what I check every test case against.
But over time, I started noticing something. Some of the most important quality questions weren’t only about whether the code worked. In any product, a feature can behave exactly as specified and still benefit from a deeper conversation about how well it serves the user’s workflow in practice.
That’s when I started asking a broader question: how can QA help keep the user’s problem visible throughout the process?
Earlier Than Testing
For most of my time as a QA engineer, I believed quality lived at the end of the process. Requirements come in, developers build, and QA checks. If all the test cases passed, the work was done. That was my definition of quality, and for a long time, it felt complete.
In many software teams, QA is most visible through testing: reviewing a build, running test cases, filing issues, and retesting fixes. That part of the role matters, and it always will.
But QA can also create value earlier. The earlier quality questions enter the conversation, the more they can shape clarity, alignment, and confidence around what is being built.
The questions I was raising during testing often pointed back to the same idea: quality is strongest when requirements, user context, and implementation stay connected throughout the work.
I still ask, “Does this match the requirement?” But now I also try to ask the broader version earlier: how does this connect back to the people we are building for?
Listening Before Testing
I joined a small cross-functional group at Solve Education! to spend time listening to our program team. There were three of us: a fellow QA engineer, a UI/UX designer, and me.
The program team runs learning programs with real communities: students, young people building workplace skills, learners from all kinds of backgrounds. They sit between our product and the people it’s meant to help, and they are also users themselves, navigating admin tools to manage programs and track progress every day.
I came with questions. But going into those conversations, I wasn’t sure what to ask. My instinct was to think in terms of test cases: what needs to be verified, what could break, what edge cases exist. But those questions don’t land well before there’s anything to test.
The harder challenge was figuring out what kind of information would actually be useful for shaping requirements. A bug is easy to describe. User context is harder. When someone tells you how they use a product in the field, not everything translates directly into a requirement or a test scenario.
The shift that helped most was learning to ask for stories instead of opinions. Questions like “Does this work well for you?” tend to get polite answers that don’t tell you much. But questions like “Can you walk me through the last time this was hard?” opened up things I wouldn’t have thought to ask about. I started to understand that the most useful information wasn’t in what people said they needed. It was in what they described doing, and especially in the daily realities and routines that shaped how they worked.
What I heard gave me a perspective I couldn’t have built from test cases alone. Not because anything was technically broken. The features worked as specified. But it gave me a richer picture of how the product fits into their real work than I had before. A picture that no test case had surfaced for me.
Those conversations reminded me that a product is not experienced as a checklist of requirements. It is experienced inside real work, real learning journeys, and real constraints.
What stuck with me wasn’t any single finding. It was how much stronger the quality conversation becomes when we stay close to the people we are building for.
Sometimes the output of those conversations is not a new requirement right away. Sometimes it is a clearer assumption, a better edge case, or an open question the team can address earlier.
Quality Before Code
Quality started to feel bigger than testing for me.
In any software product, a feature can pass every test case and still benefit from a deeper product conversation. That’s why quality has to include both the behavior of the software and the context of the people using it.
Think of it like a doctor who reads every lab result correctly but never speaks to the patient. Technically thorough. But possibly missing something important that only a conversation would reveal.
“Does this work?” is a QA question. But “Does this actually help the people it’s meant to help?” is a different question, and it becomes more useful when it is asked early.
At first, asking that question felt like it belonged to a broader product conversation. But the more I listened, the clearer it became that QA has a natural role there too: connecting technical quality with user context.
The questions I now try to ask earlier aren’t only about edge cases or failure states. They’re also about context.
Who will actually use this, and under what conditions? What are they trying to finish when they open this screen? What would make this feature feel useful, not just correct? Is there an assumption embedded in this requirement that hasn’t been checked against real user behavior yet?
Catching a bug in a test case still matters. But sometimes the more useful thing I can do is raise a question early: how can we make sure this direction stays closely aligned with users? That question, asked early, can strengthen the work before it ever reaches a test environment.
This does not mean QA replaces product or design decisions. It means QA can bring another lens into the conversation: how the work might behave once it reaches real users.
What I’m Learning Now
The most concrete shift is that I now try to join the discussion when requirements are being written, not after. For me, this can mean reviewing early drafts, listening to user context before test planning, or asking questions that help the team clarify what success should look like.
What I’ve noticed is that this changes the kinds of questions I bring to testing. When I already understand the user context, I write better test cases: not just more scenarios, but ones that reflect what users are actually trying to do.
What I’m learning from those conversations, about what our users need most, and what their work really looks like day to day, adds context that no test case can fully capture on its own. The lesson wasn’t only in the code. It was in learning not to treat a passed test as the end of the quality question.
I’m still learning how to ask better questions. But now I know QA can contribute even more when it is part of the quality conversation from the beginning.
Maybe quality isn’t just something we check at the end. Maybe it is something we protect from the beginning.