Skip to main content
lewisp707
Space Cadet
March 24, 2026

Challenge: Have you ever caused a bug in a live application? And on a scale of 1-10, how much chaos did it cause?

  • March 24, 2026
  • 13 replies
  • 342 views

... Because I have, a couple of times. The most chaotic one was while working on a national health application in the UK, where my refactor to the API which made the application more testable meant that patients nationwide couldn't access information about their prescriptions for a couple of hours during the day. The panic set in realising that my changes had gone through to production too soon... Revert revert!!!

I would rate that a 7 out of 10... Do you agree? Anyone got a more severe bug than that?


Share your failure story in the comments, and I will pick three winners who will get the book “Contract Testing in Action. With Pact, PactFlow, and GitHub Actions” from ShiftSync.

The challenge closes in 10 days.

 

 

13 replies

parwalrahul
Navigator
March 28, 2026

I have caused real physical IoT device to crash and get bricked from my software testing.

 

I test IoT software that gets loaded in to smart industrial IoT devices. I once tested a usecase where if the loading of firmware on one device was ON and if you try to access it from another instance of the web browser application; the access was possible (BUG 1).

The worst side effect was that, you could even trigger a parallel software upload to this device in this new application instance. (BUG 2).

RESULT: Device got bricked. (BUG 3)
 

After Bug 3: No LEDs. No response to reboot. Nothing…  This was a 100/10 issue for us.

 

It was a big issue for us as our devices were already there in the market and then we had to fix this issue and roll out the updated software application that restricted all this.

This one bug taught me a lot about IIoT industry and why it is regulated to some degree. 

Testing uncovers interesting lessons. Thanks for this challenge, Lewis.

 

 

https://testingtitbits.com/
Space Cadet
March 30, 2026

Scale of DESTRUCTION: 11!

I used to work creating dynamometer test rigs control systems. We asked the customer for a list of control commands and added them to the drop-down control in the order they gave them to us. STOP being the first one on the list made sense as a default setting. And as the users were expert users we didn't question any further. 

Roll on a few months after release and we got a report that one of the test cells had exploded, causing about half a million in damages! 

It turns out that the worst thing you can tell a powerful dynamometer to do while the engine is at 9k RPM is to STOP. It applies an opposite and equal force and tired to stop the drive shaft instantly. Anyone who understands a rudimentary grasp of physics knows that this is bad! The engine exploded and pistons embedded themselves into test equipment and destroyed everything. 

The cell operators fell back off their chairs at the explosion, although this was the only injuiries they sustained. 

Someone had dropped a command step in and forgot to change it from the default setting. COAST command is what they wanted. A nice controlled coast down in power. 

That day I learned that you should always question assumptions.

PolinaKr
Community Manager
April 7, 2026

Thank you everyone for participating in this challenge! And special thank you to ​@lewisp707 for hosting it🎉

Our winners are:
@RichHintonTests 

@jayhco 

@maryia.tuleika 

I will reach out to you shortly to organize books delivery!💌

And may the quality be with you