A Philosophy for QA: The RISK Framework
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 RISK 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. It’s a belief system.
I’m calling it the RISK Framework — Risk, Independence, Systems, Knowledge. Here’s what each piece means.
R — Risk
QA is the practice of surfacing software quality risks, independently, throughout the software development lifecycle. 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.
Software testing is collecting information about system behavior. 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. But testing is one tool QA uses. Surfacing risk is bigger — it means identifying risks early, analyzing and prioritizing them honestly, communicating them clearly, and working with stakeholders to figure out what to do about them.
I — Independence
You’ll notice that my definition of QA includes the word “independently.” This distinction is critical, because QA comes to the software without the assumptions of the people who built it. That blank slate is the structural advantage. Developers lose it the moment they write the first line of code. It’s not that they lack skill or effort. They just can’t unknow what they already know. Independence is what makes QA’s risk picture different from anyone else’s on the team.
S — Systems
QA’s knowledge is system-wide. Not just one module, or one feature — the whole product, end to end, the way a real user experiences it. Good QAs spend the majority of their day inside the app. They know how it actually works, where the edges are, and what nobody has checked yet.
K — Knowledge
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. 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 risk picture that gives the team confidence to ship.
QA doesn’t own the decisions. Stakeholders do. QA owns the information that makes those decisions possible.
That information is what turns blind confidence into informed confidence. It’s 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 RISK Framework at a Glance
- QA = the practice of surfacing software quality risks, independently, throughout the software development lifecycle
- Software testing = collecting information about system behavior
- How we surface risk = 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
That’s RISK. Risk, Independence, Systems, Knowledge. When I’m lost, I run through those four words and it orients me faster than any checklist.
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 obvious objection is that QA already has definitions. ISTQB has official language. Context-Driven Testing has a philosophy. James Bach and Michael Bolton have written extensively about what testing is and their definition of testing as a process of learning about a product through exploration is actually close to what I’m saying here.
So why make up your own?
Because none of those gave me what I needed when my manager suggested replacing QA with devs testing. I couldn’t explain why the business needed our team. From what I understand, ISTQB describes what testers do. CDT and RST get closer to the spirit of what I’m saying — testing as learning, context over process — but they didn’t give me a way to answer the question I kept getting asked: what is QA’s organizational purpose, and why can’t anyone else do it?
That’s what the RISK Framework is trying to answer. It’s not a replacement for existing thinking — it sits on the shoulders of all of it. But a way of internalizing it that I can actually use when the ground shifts.
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 RISK Framework should be stress-tested.
And if you’re newer to QA and something here clicked — awesome. Welcome to the world of QA. It’s more interesting than it looks from the outside.
