What Not to Test When You Have Less Time

“Show me what you won’t test. And I will tell you how good your strategy is.” — A Director, I worked with during a release crisis (in 2012)

Hi !!!

Twenty‑plus years in testing.

After working for 20 years in testing vertical, I have learned a lot.

One of them is: a late‑night release rarely fails because teams didn’t work hard enough. But,it fails because we didn’t select hard enough.

We tried to test everything.Diluted focus, and shipped with blind spots in the crucial places.

Today I will show you the three‑lens system.

I now run this system in every high‑pressure release. It has saved us from outages, losses.

It saved weekends for entire teams, and importantly,built leaders trust that QA can make business decisions, not just test bugs.

The Scenario You Can Relate To

It is Friday, 8:05 PM. Release is tomorrow at 6:00 AM Jira shows 186 test cases. You have enough hands for 40-maybe.

Developers on MS Teams are asking if their fixes made the cut. Product Manager wants “just one more quick validation.” DevOps team reminds you the rollback procedure takes two hours if the database is involved.

Sound familiar?

When time is critical, many teams prioritize the quantity of tests over strategic focus. They attempt to execute a number of tests overnight.

And potentially overlook the most crucial user flow.

A more effective approach involves being selective and concentrating testing efforts on the limited but most important flows /features of the product.

Here’s the alternative.

Lens 1 · Business Exposure

Ask three blunt questions for each bug /feature :

1. Revenue Flow: Could failure impact the financials ?
2. Customer Trust: Could it leak data or lose trust?
3. Public Shame: Will the bug appear on a page of which customers can screenshot?

If the answer is yes to any one of these, the test stops.

Hold the release.

Why?

Because these failures have magnifiers:

1. Finance
2. support queues
3. social media.

They are costly.

Far more costlier than internal escalations.

Here is an example : Latin American E-com Product 2012.

The E-commerce product had a coupon field on the home page.

It was broken. It led to a 6 % drop in weekend revenue.

The fix took an hour. But the reputation cost lingered for weeks.

That flow later got top priority then onwards.

Tip: keep a living worksheet of your “money & trust” paths. Update it quarterly so triage calls take minutes, not debates.

Lens 2 · Blast Radius × Fix Speed

Note:Blast Radius can be termed as Impact Radius.

Every risk has two axes:

Blast Radius X Fix Speed Matix

Why it works:

Time is limited.Always.

Testing a “big blast, fast rollback” item for six hours steals coverage from a “big blast, slow fix” area that could impact the business for days.

Use the matrix on a whiteboard.

Put each change in a square. Align test depth to that square.

It takes five-seven minutes. But saves seven days of finger pointing later !

Lens 3 · Observability Credit Score

Testing depth should match how fast you can see failure in production.

That is, fail fast. Score every component in the scale of 0–5:

• 0: No logs, no alerts-blind. Test heavily.
• 3: Structured logs, pager alerts-moderate cover.
• 5: Distributed tracing, dashboards, anomaly detection-minimal pre‑release; trust prod monitors.

In 2015, a client I was working with,reduced mobile‑web UI testing by 60 % after adding client‑side error logging.

We saw crash spikes in the logs.Within five minutes patched with a one‑line fix.Customers never noticed !!

Invest in telemetry; it helps you with test cuts.

Pulling the Lenses Together — Real Numbers

Here is the example of how we reduced the number of testes by using these 3 lenses.

Impact of Blast Radius X Fix speed matrix

Outcome:

Release shipped on schedule: Two low‑severity bugs in production, fixed on the same day ~120 engineer‑hours saved

Hard Lessons I learned

1. 2007: Ignored Lens 3 (zero logs). A silent null pointer caused 48‑hour outage.
2. 2011: Fought marketing pressure-won. Skipped a banner test, focused on checkout. Saved the release.
3. 2020‑present: Every release uses all three lenses in a 15‑min call. No Sev‑1 wake‑ups since.

How to Run This Next Sprint

1. Block 15 minutes at the start of your release freeze.
2. Stakeholder huddle: QA lead, dev lead, product owner, ops.
3. Whiteboard: three lenses, sticky notes for each change.
4. Sign the “won’t‑test” list and publish it in release notes.
5. Log hours saved-use the data to argue for telemetry

Ready to Try It?

I have turned this entire process into a single‑page checklist.

It is easy to pin near your release board. It includes the three‑lens prompts, a quick scoring grid, and the fast‑fail red flags that should halt any deployment.

Grab the checklist here

Question for you: What is the boldest test you have ever pushed out of scope under deadline pressure?

Did it save the schedule -or bite you later?

Bye for now !

Thanks,

Jayateerth !

Connect me on LinkedIn

© 2025 Jayateerth Katti · You have permission to share this article with your team unaltered.