Context-driven testing rejects the notion that there's a universal "best practice" for QA. Instead, it holds that the value of any testing approach depends entirely on the context you're operating in. What works at a regulated bank with 50 QA engineers is actively harmful at a startup with one contractor and no formal QA process.

And right now, that distinction matters more than ever.

AI is creating a false sense of coverage. Teams are generating thousands of test cases with LLMs and mistaking volume for coverage.
Without proper context, you end up with beautifully written test cases that miss the actual risk entirely.

In startup environments especially: apply heavyweight process to every feature and you'll be ignored. Test everything equally and you'll miss what actually matters to your customers.

Imagine a scenario where you have limited institutional power, the company you work for has customers with high ARR who can escalate over your head, and has no established QA process to lean on. Context driven testing gives you a better vision for every decision: rather than just testing the feature, you can ask things like "What's the actual risk if it breaks?" or "Who is most likely to be harmed if we miss this?". Those two questions do more work than any test plan template.

Context driven testing is not an excuse to do less testing, it's actually the opposite, since this is way harder, it requires to develop critical thinking and really understanding the user needs and areas with greater risks, not just tooling.

Do you apply context-driven thinking in your daily work? What's the highest-risk area in your system right now?