Back to Blog

You Don't Change the Oil Filter on a Parked Car

Galit Lisaey
change oil

You Don't Change the Oil Filter on a Parked Car

A brilliant quote (not mine!) from my outsourcing partner, during a deep discussion on UAT — User Acceptance Testing.


The conversation revolved around a common question in many project teams: Why don’t we include high-risk scenarios or exceptional conditions in UAT testing?

In my view, the goal of UAT is to confirm that the system supports real business processes — not to test extreme or unlikely conditions.

UAT is about ensuring the "driver" knows how to operate the car and that the car was delivered according to specs. We’re not testing if it can survive a Formula One race.


So, when do we test exceptions and stress conditions?

Great question — and one that always comes up.

Yes, exceptional and boundary conditions need to be tested. But they should be addressed earlier in the project lifecycle:

  • During initial environment design

  • Through internal unit testing

  • In configuration planning sessions

  • As part of risk assessment

Stress testing and validation of unusual paths are part of a broader testing strategy — executed where risk justifies it, not during UAT.

That’s why UAT must be seen as part of a bigger testing puzzle — not the stage for every imaginable scenario.


Risk-Based Thinking – the Key to It All

We don’t skip challenging scenarios — we place them strategically.

A solid risk-based approach asks:

  • What could go wrong?

  • What would the impact be?

  • Where’s the best place to test for it?

This is how we design an efficient test strategy that targets what matters — without overloading UAT with unnecessary edge conditions.


In Summary:

UAT is essential — it verifies the system is ready for real-world use.

But it’s only one piece of the puzzle.

Strong project planning means acknowledging we won’t catch every issue before go-live — and being prepared to handle the unexpected.

The real question is: How well did we plan for what we couldn’t predict?


How do you define risk-based testing scenarios in your projects? And how does that influence your overall strategy? I’d love to hear your thoughts from the field.

Related Posts