Describe the worst test strategy you ever worked with, in one sentence.

as a automation engineer in my startup company, relying on a containerless, un-versioned pipeline where developers push untested code directly to the production cluster at 4:55 PM on a Friday, using arbitrary manual clicks as the sole validation matrix, while praying the microservices don't blackout in the middle of the night.

Our test strategy was: deploy on Friday, pray on Saturday, hotfix on Sunday, and call it ‘Agile’ on Monday — while production quietly served as our staging environment. We confused Continuous Delivery with Continuous Recovery.

Answer Richard Seidl’s question for a chance to receive a ShiftSync giftbox.

 

The strategy was to trust the developer’s fixes and not retest all the bugs in the next cycle. We only have one big cycle and should test just once before delivery.

The worest test strategy where there 

No clear objective

No clear goal, entry or exit criteria even test objectives also there is no participation from all stakeholder 

Worst test strategy was a copy of 30 different public available slides from internet collected by an internship not matching to any aspect of neither test scope nor test object.

No strategy at all — just 'click around and see if it breaks' two days before release.😉

The worst test strategy I’ve seen was treating production like a QA environment deploy first, hotfix later, while developers were constantly pulled into competing priorities.
Releases, urgent fixes, and shifting priorities all happened at once, with no protected testing window.

I have faced these two worst scenarios multiple times-

1. “No requirements, no test cases, no timelines - just ‘please test everything.’”
2. ‘We don’t need QA, developers already tested it.’”

“Just test it like you are using it on the front line.  But what did you change? You are the SME, you should know.” 🤦‍♀️