Automated test cases are a wonderful thing in theory. It’s great to be able to just set them running overnight and see what failed in the morning. But if your test scripts aren’t robust, then your cases are going to be as unreliable as a clock made of jelly, and that will make the test result analysis as painful and confusing as a jumping castle full of porcupines.
The most important thing to realise about writing test scripts is that test scripts are designed to fail. Having a heap of passing test scripts like ordering all the deep fried stuff off a yum cha menu – it looks alright, it tastes alright, but who knows what’s really in those things? You may not find out until it’s too late and you’re staring at the remains of your stomach on the floor, screaming “Why? Why did I not make my test scripts more robust?”
Well relax, because Trish is here to help you. Let’s take a look at an example test case:
“Verify that when a banana is put into a banana machine, banana juice comes out the juice tube.”
Sure, when the banana machine is working, you want the automated script to pass. But when it’s not working, you want to know exactly why. What you don’t want is your script to run and give you a message such as “FAILED! BANANA MACHINE IS NOT WORKING AS DESIRED!!” because then you will spend the rest of the day trying to figure out why and you will just end up tired, angry and covered in banana. And nobody wants that.
So have a think about what will go wrong and prepare for any scenario. In this case, you would think of the obvious first, such as the banana juice NOT coming out of the juice tube. So obviously you will want a message stating that “banana juice did not come out of the juice tube.” But what if something goes wrong before then? Obviously you will want to know about that too, otherwise your test case will be telling you “banana juice is not coming out of the juice tube” when really, the whole banana machine is on fire. You have to admit, it’s a bit of an understatement. So for this test case I would make sure that at the very least, appropriate error messages are able to be output for the following scenarios:
– Banana juice coming out, but not from the juice tube
– Some other kind of juice coming out of the juice tube
– My test case just dying because something else has gone completely and horribly wrong
This usually isn’t as tedious to do as you might think. A general rule of thumb is to not have any IF statements without ELSE statements accompanying them. And you will find that once you have written a few test cases this way, you can generally use the same logic over and over.
I’ll probably expand on this a little later but hopefully this should tide you over for now.