There were still a few remaining questions from our webinar with Srilu Pinjala in July on Test Case Development – So You Think You Can Write A Test Case that we wanted to address.

It was Srilu’s opinion that test cases should be very detailed and document the functionality of the software. Her view was that this way test cases can then be used by anyone and at a later date. She coined the phrase Test Like a Robot which I found interesting. Should one really want to be like a robot? Obviously we want to use our brains which robots don’t have (yet). Though testers might take her phrase to be slightly derogatory (“we are humans, not robots”), her meaning was that test cases should be documented in such a way that they can be easily followed (by a robot), with step-by-step instructions on how to get to a page and function on an app, etc. It’s easy to relate. Unless you are a domain or product expert, if you take a test case that is not written clearly, you can come up with different results or not even execute what you were supposed to.

Here are the additional questions from the webinar and Srilu’s responses:

Q. What if there’s a limited time to test the app, will it be appropriate to use the robot type of test case writing?

A. Yes, it is still appropriate, but get creative. Robot-type test case descriptions are admittedly redundant because you need to repeat navigation or other logic steps to make them complete. You can copy paste most of the steps and edit a few things and you have your test case.

Q. Can a picture suffice as an expected result? Instead of using words?

A. (Can you identify the differences between the two pictures?) A picture says a thousand words. Absolutely use a picture whenever descriptions become complicated or too long to type in. Take it one step further and highlight (using MS-Paint or other tools) the elements that need to be verified. The key is to pinpoint the expected result and get the testing done quickly.