Somewhere out there, someone cut testing time by 40% to ship faster. This quarter, they’re spending 60% of their time fixing what they shipped.

The math doesn’t work.

Teams under pressure make the same trade thinking they can sacrifice testing now without paying compound interest later. The debt always comes due faster and costs more than anyone predicts.

Someone recently introduced me to a prioritization framework that’s stuck with me: food, water, oxygen. Oxygen is non-negotiable—you die without it in minutes. Water is critical—you last days. Food is important—you survive weeks. Simple way to distinguish between “must have now” and “need eventually.”

Many suggested that testing was like food. Important but deferrable under pressure and comparable to other features and enhancements.

I disagree. Testing isn’t food. It’s oxygen. You just don’t notice you’re suffocating until you’re already brain damaged.

The Blast Radius Question

That said, not everything deserves equal testing rigor—there’s layers within the food, water, and oxygen framework. That’s obvious when you think about it, but easy to forget when deadlines loom.

The question isn’t “should we test this?” It’s “when this breaks, what else breaks with it?”

Authentication fails? You’ve exposed user data or blocked legitimate access. Payment calculation is off by 1%? You’ve got regulatory problems and lost customer trust. Data migration goes wrong? You’ve lost weeks of progress and months of trust recovering from it.

Database changes, payment processing, auth flows, critical user workflows—these are oxygen. When they fail, your product stops being your product. Sometimes immediately, sometimes slowly, but always catastrophically.

Then there’s the stuff that matters but won’t kill you if it breaks briefly. Third-party integrations fail visibly. Background jobs can be rerun. Error handling gaps get discovered and patched. These are water-level concerns. Critical, but you can survive short-term without perfect coverage if you’re monitoring closely.

And then there’s polish. UI edge cases, experimental features, internal tools with small blast radius. Important eventually, but survivable if wrong initially. That’s food-level testing.

What We’re Actually Prioritizing

Let’s be honest about what oxygen, water, and food mean in practice.

The hard part isn’t the intellectual framework. It’s the moment your engineering lead says “we can ship Friday if we skip integration tests.”

Next sprint never comes. Or it does, but now you’re fixing production issues instead of writing the tests you deferred.

Making Testing Cheaper Than Skipping It

The usual testing advice—“just do it,” “make time for it”—doesn’t help when resources are actually constrained.

What helps is making testing fast enough that skipping it feels slower.

Smoke tests for oxygen-level systems. Not comprehensive coverage—just “does this work at all” validation. Authentication succeeds with valid credentials? Payment calculates something reasonable? Data persists and retrieves correctly? These tests run in seconds and catch the catastrophic breaks.

Build test templates for common patterns. CRUD operations get the same shape every time: valid input succeeds, invalid input fails appropriately, authorization works, audit logging captures changes. Write the template once, inherit it everywhere. New endpoints get comprehensive coverage faster than writing them without tests.

Feature flags let you ship changes to small user subsets. Not a substitute for testing—another validation layer for features where comprehensive testing would take longer than iterating on real feedback. Only works if you can see when things break, so solid error tracking is prerequisite.

Scale your testing infrastructure to match team capacity. Solo developer? Focus on oxygen tests and monitor closely. Small team? Add integration tests for water-level concerns. Larger teams can afford comprehensive coverage and performance benchmarking. Trying to maintain enterprise-level testing with startup resources means you’ll skip testing entirely when pressure hits.

When to Hold the Line

Pressure to cut testing corners is inevitable. Sometimes negotiate. Sometimes say no.

Auth changes, financial calculations, regulated data, core workflows, database migrations—these aren’t negotiable. Skipping tests here means accepting catastrophic risk. “We’ll fix it if it breaks” isn’t a strategy—it’s hope disguised as planning.

Polish features, internal tools with small blast radius, experimental features with rollback plans, optimizations where the current version works—these are negotiable. They matter, but they won’t kill your product if wrong initially.

The key is articulating why in business terms. “We need to test this because HIPAA violations cost $50,000 per incident” or “This will be front page news in the WSJ” lands differently than “we need to test this because it’s best practice.”

One Thing to Try

Don’t revolutionize your testing approach. Pick one thing.

• Under-testing? Identify your three most critical workflows and write smoke tests this sprint.
• Over-testing? Move comprehensive non-critical tests to nightly runs.
• Constantly debating priorities? Document oxygen/water/food criteria and remove the debate.

The goal isn’t perfection. It’s ensuring the things that would kill your product if broken get the oxygen they need.

You’re Already Suffocating

Teams treat testing as optional and insist they’re breathing fine. By the time symptoms appear—production incidents, customer complaints, regulatory issues—the damage has already occurred.

Resource constraints are real. Time pressure is real. Pretending testing is deferrable when the blast radius is catastrophic is slow-motion suffocation.

Test first for oxygen. Test adequately for water. Test pragmatically for food. And never convince yourself that testing critical systems “later” is anything but self-deception.

What’s your team’s oxygen? If you can’t answer immediately, that’s your first problem to solve.