This idea came to my mind as a joke, I thought to myself “What if Mythbusters were software testers” and to be honest, the more I think of it, the more similarities I find between software QA job and the Mythbuster’s job. Of course not that QA’s are always trying to blow up and brake things, but that too. The main reason I find so many similarities is the process, the approach that Mythbusters use to attack the so called “myths”, and all of them look so much like a test plan. Here’s how it can be compared in a few simple examples.
Myth vs. test case
To give some visual representation on what I am talking about, let’s first take a look and this short video, a really typical example of mythbusting:
So, long story short – the myth is: if you mishandle a revolver, you may get your thumb ripped off, pretty simple. And there’s our first similarity – this sounds pretty much like a test case – we have the user story – “as a user I should be able to rip off my thumb if I mishandle the revolver” and the exit states – “Pass” thumb lost – myth confirmed and “Fail” all fingers in place and myth busted.
Setting up “busting” environment:
As we could see from the video, Jamie and Adam started by first setting their testing environment – get a gun, get the high speed camera and of course – the artificial hands.
There’s one important thing not to be missed here – poorly designed testing environment leads to a corrupted result. In this specific case – the “hand” that Jamie created was not realistic enough and the damage it took wasn’t as much as expected. So one important conclusion to make out of this is – always design your test cases to mirror the real world and to be objective. Non realistic test cases will just compromise the test results.
Time for myth testing
As you could already guess the attempts to “bust” the myth are the tests executed themselves. In this specific case it was a mini myth and I deliberately have chosen it but if you review any other myth you would see the exact same pattern.
And one last thing…
This was actually the main idea behind this whole article, if it isn’t blowing up, blow it up anyway. You could probably observe this in every bigger myth they deal with – they set it up, they test the so called “happy path” and if it doesn’t bust the myth, they repeat it but this time under extreme conditions.
Well in software testing this is called stress testing – it consists of testing your system, application or functionality under extreme conditions to check if it’s stable enough. This is a very important thing to learn from thеsе guys, you have to know how to break it, even if it’s in a ridiculously weird manner. The important part here is – better know where it crashes and decide if it’s “Ok” to go live with it, instead of letting your client find it and have yourself in the role of the “bad guy”. It’s vital to remember to test all positive paths first, before starting to hit the application with everything you have. Other wise you may fall in let’s call it “negative testing trap” which means getting so focused on “breaking” the app, that you may actually miss all defects that appear in it’s normal flow, and you really don’t want this to happen.
So, myth testing or software busting, what we should always aim as software testers is in first place – knowing the product we are testing and all it’s capabilities and of course test all the possible ways to destroy it, positive or negative ones.