Project Retrospectives · Published July 21, 2026
Retrospective: The Cost of Compressed Testing
To hit a client's opening date we cut testing from three weeks to one, then spent six weeks fixing production.
The client had a public commitment date and required launch that day. We agreed to compress testing from three weeks to one. The system was available on launch day, and we spent the next two months patching.
What surfaced after launch
Concurrent orders drove inventory negative, a gap that concurrency testing would have caught.
The nightly settlement job mishandled time zones, so two days of reports did not reconcile.
Some mobile pages showed blank screens on older browsers; compatibility testing was skipped entirely.
Lessons
If something must be compressed, compress scope and visuals, never testing of core flows.
Assign two people to on-call during the first week so issues are closed the same day.
Build buffer into quotes and schedules instead of discovering there is none when the client pushes.
Schedules are negotiable; quality is not. The two weeks saved on testing were repaid with six weeks of fixes and a loss of trust.
← Previous post
Approval Flows: Do Not Turn Organisational Problems Into Software Problems
Next post →
Feedback Should Not Wait for Year-End
Want to apply these ideas to your project?
We are happy to go deeper into implementation details, or to discuss the specific questions you are facing.
Start a conversation →