The Ten Commandments of Software Testing
Facebook don’t test. Why would they? With an active user base of more than one billion, it’s all-but impossible for them to create a staging server which bears any resemblance to their live environment at all.
All Facebook developers are able to push to production. And if it blows up, so what? It’s still in keeping with the company’s original ethos to move fast and break things. They even broke their Android app on purpose just to test their users’ loyalty.
Unfortunately, the rest of us don’t have the luxury of Facebook’s world-devouring scale. Even with the most well-oiled continuous deployment loop, we’ve got to test stuff. No one wants to take a call from their Managing Director when the system’s tanked during a major client demo thanks to an untried update that just went out.
From being in the trenches when a £500m corporate software implementation imploded on release day (despite five years worth of planning) to watching a quick-and-dirty MVP become a NVP because a button didn’t work, I’ve learned a lot about testing in my career. And sometimes I still get it wrong.
Even Sage, a FTSE 100 company and one of the most recognized software brands in the UK, hold “Prayer Meetings” before they push out a major update.
As a product manager, you need to be acutely aware of Murphy’s Law. Whatever can go wrong will go wrong; it’s how you deal with it that matters.
Here are my Ten Commandments for Software Testing:
- EVERYONE owns quality
- Test your own code
- Evidence your test results
- QA isn’t there to mop up sloppy development
- Nothing goes out untested
- Always verify new features and fixes in production
- Try and break stuff
- If it’s broken, FIX IT
- User feedback matters; they’re your ultimate testers
- Bugs happen; it’s how you handle them that counts