Test Cases – the search continues

The search for the perfect test case format I mean. Ideally a test case document should be such that any n00b can just come along, never having seen your application before and test the bejeezus out of it.
 
So ideally, each test case should somehow communicate:
  • How to get to the area you are testing.
  • What to do when you get there.
  • The expected result.
The problem is that these test cases should still be brief enough to be able to write them up quickly for a new application or change request. So I’m thinking the following format is pretty good:
 
Pages: This is whatever page or pages you are testing.
Method: This is what you need to do in order to achieve the expected result.
Expected: This is what should happen once you have followed the method. If it doesn’t happen, then the case fails.
Requirements: This references any requirements this is related to.
 
The pages should just be references to a list of all testable pages in the application and how to access the pages. Having a master index of the pages and how to get to them would save a lot of copying and pasting and a lot of training in how to use the application.
 
The method should just be short and to the point. I really don’t think there is any need to spell out the purpose of the test case – that should be in the title or in the referenced requirement. The whole point of any test case is to do something and see if the result matches the expectation.
 
I think having an expected field is important, as I have encountered some test cases that just ask you to verify if something “works”. This field would encourage the test case author to consider what defines the something “working”.
 
The requirement should of course reference a larger list of requirement descriptions and I believe this should really be a last resort as a place to understand what the test case is about. There have been too many times when I have had to go to the requirement just to figure out the context of the test case (ie. what page am I even meant to be looking at).
 
I believe this is a good starting point in the quest to find the ideal test case format so that one day, you can just sit down any new tester of any experience level and ask them to run a few manual tests so that they are able to get through them quickly and easily with minimal bother to the other testers.
 
Apologies for the lack of hilarious analogies in this post, I’ll think up something like that for my next one.