What QA Is: A Framework Five Years in the Making
In grad school I was researching how students debug their code. I came across something called Information Foraging Theory — the idea that people hunting for information follow certain scent trails, signals in the environment that promise high-value information for the least amount of effort. Like an animal following a smell toward food.
I wasn’t thinking about QA at the time. I was thinking about students staring at stack traces, deciding which error to chase first. But something about that idea stuck. The notion that finding useful information is itself a skill. That you can be good or bad at knowing where to look, how deep to go, when to stop.
A few years later, stuck in a pandemic shower longer than I should have been, I had a eureka moment — software testing is just collecting information. That felt true and gave me some peace. But it was incomplete.
It’s taken me another three years to figure out what was missing. This post is my attempt to finally say it all in one place.
The Framework
I want to be upfront: this is my current thinking. It will probably evolve. I’m sharing it because I needed a foundation — something to return to when a new challenge lands on my desk and I’m not sure how to think about it. Not a tutorial. Not a process. A belief system.
Here it is.
Software testing is collecting information about system behavior.
That’s the activity. You’re gathering data about how the system works, where it breaks, what it does when you push it in unexpected directions. Information foraging, just like the theory said.
Testing is one tool QA uses. But QA is bigger than testing. It starts before the first line of code is written and doesn’t end at release. The job is to proactively make risk visible — not just find bugs.
Making risks visible means four things in practice: identifying risks early, analyzing and prioritizing them honestly, communicating them clearly to the people who need to know, and working with stakeholders to figure out what to do about them. QA doesn’t own the decisions. Stakeholders do. QA owns the information that makes those decisions possible.
QA’s core skill is producing knowledge about system risk.
Not finding bugs. Not running test cases. Producing knowledge — structured, documented, independent, system-wide — about what’s working, what isn’t, and what nobody has checked yet.
This is the part I think the industry undersells. Every QA activity, when done well, is a knowledge production activity. Exploratory testing produces knowledge. Documented test suites produce knowledge. A release recommendation produces knowledge. Even saying “I didn’t test this area” produces knowledge — because now the business knows what it doesn’t know.
The skill is turning raw testing activity into something the organization can actually use. Not a feeling. Not a vibe. A risk picture.
The tangible output is confidence — for stakeholders to make informed business and technical decisions.
This is what QA produces that you can point to. Developers produce working code. Product managers produce defined requirements. QA produces the confidence to ship.
Not blind confidence. Informed confidence — the kind that comes from knowing what was validated, what wasn’t, and what risk the organization is knowingly accepting. That’s what a clear risk picture gives you. And it’s what’s missing when QA isn’t doing its job well, or isn’t in the room at all.
The ultimate goal is protecting revenue and the end user experience.
Bad software has real consequences. Customers churn. Trust erodes. Incidents cost money to clean up. QA’s job is to reduce that exposure before it happens. For most companies that means protecting the business and the people using the product. In some contexts — healthcare, edtech, safety-critical systems — the responsibility goes deeper, into territory that’s less about revenue and more about genuine harm. The framework holds either way. The stakes just change.
The Framework at a Glance
- Software testing = collecting information about system behavior
- QA = the practice of making software quality risks visible from an independent perspective throughout the software development lifecycle
- How we make risk visible = identifying, analyzing, prioritizing, communicating, and working with stakeholders to mitigate risks
- What QA owns = the independent, structured, system-wide risk picture
- What stakeholders own = the decisions informed by that knowledge
- The tangible output = confidence for stakeholders to make informed business and technical decisions
- The ultimate goal = protecting revenue and the end user experience
Why I Needed This
I’ve been in QA long enough to have been asked by friends and family “what do you actually do?” and by coworkers on other teams “what is QA anyways?” For people outside of work I would give a simplistic answer like, “Oh, I just play with apps to make sure they work.” And for coworkers I would give some version of “I find bugs before customers do.” Which is true but insufficient. I didn’t really know how to explain my job, what QA was, and what purpose it served. I just intuitively knew it was critical to the business.
This came up as well when my manager shared his concerns about our department getting replaced by devs testing. I knew it was a bad idea. All QAs would probably share the same feelings, but it was difficult to articulate why. And when you can’t even explain what your own job is or how important it is to the people making these decisions, you end up defenseless and less able to advocate for yourself.
More than just job security, I think the framework helps you grow and stay grounded as a QA.
The framework matters because without it you’re just following someone else’s process. You can execute a test plan someone else wrote. You can file bugs in the format someone else defined. You can follow a tutorial. But when something genuinely new comes up — a new situation nobody has a playbook for, a stakeholder asking a hard question, a team that wants to eliminate your function — you need a foundation to reason from. Not a tutorial. A way of thinking.
That’s what this is for me. When I’m lost, I come back to it. What information am I trying to collect? What risk does that information reveal? Who needs to know? What does good knowledge production look like here? What would giving stakeholders genuine confidence actually require?
Those questions don’t answer everything. But they orient me. And orientation is usually enough to start.
Where This Probably Gets Challenged
The most likely pushback is on “making software quality risks visible” as a definition — the argument being that other roles surface risk too. I’d argue there’s something structurally different about QA’s version: it comes from a place of genuine independence. It’s not independence in an adversarial sense. QA isn’t trying to break things or hunt for developer mistakes. It’s that QA comes to the software without the assumptions of the people who built it. That blank slate is the structural advantage.
Have you noticed why QAs keep finding those bugs that no one else on the team did? It’s not because we’re actively seeking failures but because we’re genuinely learning how the app works. The bugs literally pop out at us because we’re so independent and detached from how the code works. That advantage is something developers lose the moment they write the first line of code. That’s why devs testing their own code isn’t a substitute. It’s not that they lack QA skill or effort. They just can’t unknow what they already know.
The other challenge is the knowledge production framing. Developers know things about their systems, product managers know things about user needs. The difference I’d point to is the same: QA’s knowledge is independent, system-wide, and specifically about actual behavior which nobody has checked deeply yet. Good QAs spend the majority of their day inside the app. They know the app and how it actually works for end users like a power user. A power user is susceptible to the curse of knowledge but it’s still closer to the end user than the knowledge a dev is cursed with.
This is my current best thinking. Not the final word. If you’ve been in QA for a while and something here doesn’t fit your experience, I want to hear about it. The framework should be stress-tested, not protected.
And if you’re newer to QA and something here clicked — Awesome. Welcome to the world of QA. It’s really more interesting than it looks from the outside.
