Tuesday, March 23, 2010

Automated Testing: How to write automatable test cases?

Test cases are used in software testing extensively. Plainly speaking, a test case consists of one or more steps. The test case may have expected results given for one or more steps. Test cases commonly have other information such as an ID, a description, some pre-conditions and test data.

If you want to automate test cases without re-working them or making a lot of assumptions, you should ensure that the test cases at hand are specific. Here are some guidelines below. If you have been handed test cases authored by someone else, you can use these guidelines to determine if you need to modify these test cases before you automate them. If you are going to write test cases that would be automated later, you should follow these guidelines to make your test cases automation-friendly. Some of these guidelines are also applicable to writing test cases that are not marked for automation. I have used examples from Microsoft Word for your convenience.
GuidelinesFor example, instead ofIt should mention
1. The test case should specify each pre-condition.Not giving any pre-condition Close MS Word if it is already open.
2. The test case should not leave an action to the judgment of the automation tester.Just saying, "Open MS Word."Open MS Word from Start > Programs > Microsoft Office > Microsoft Office Word nnnn.
3. The test case should specify the test data in each applicable step. Saying, "Open any existing MS Word file."Open an existing MS Word file (C:\Abc.doc).
4. The test case should have all the required steps.Mentioning "It should be possible to save the changes made by the user." as an expected resultTwo separate steps, 1) for saving changes to a new file and 2) for saving changes to an existing file.
5. The test case should not hide some details.Mentioning "Type a word with incorrect spelling. The word should be underlined with a squiggly line."Type a word with incorrect spelling. The word should be underlined with a red squiggly line.
6. A step should not force one choice. Saying "Enter a word using the keyboard or Insert > Symbol feature".Two steps, 1) entering a word using the keyboard and 2) entering a word using the Insert > Symbol feature.
7. The test case should specify (and not imply) any clean up steps.Missing any steps to clean upThe steps to remove the added word from the Dictionary or reset MS Word to its original setting (if the test case requires a word to be added to the MS Word Dictionary).
8. The test case should describe the expected results as completely as required.Saying "Close MS Word without saving your changes. There should be a dialog box asking you to save your changes."Close MS Word without saving your changes. There should be a dialog box titled "Microsoft Office Word" with the text, "Do you want to save the changes to ...? and three buttons labeled Yes, No and Cancel."
The above guidelines should ease your struggle when you examine the test cases to automate them. Have you found any other problem with the test cases when you sought to automate them? Comment your problem.


  1. Please define automatable test case. Are you referring to a template or do you mean where a test case gets filled in from scripts accessing code and/or documentation?

  2. Actually, neither. By test case, I mean a "manual" test case with some step(s) and optionally expected result(s).
    I am not even considering the technical feasibility of the test case for automation in this post.
    This post talks about the guidelines that you should expect to be followed in the test cases that you are handed over for automation. It is all about making a test case specific so that the automation engineer may solely focus on designing and implementation of the test automation. As I have mentioned in the post, some of these guidelines may be used to design the manual test cases better.
    Thanks, it was a good question.

  3. Please suggest how can set the particular checkpoint in QTP? Just imagine if I want to check the date field with the boundry value.Then how can set the chekpoint for the same in automated testing tool?

  4. Nice post. Thanks for sharing those guideline. The steps that you have mentioned are really helpful while designing a test case. Software Testing Services

  5. Hi there,
    Code coverage is one of the most important parameter for any kind of testing. In software testing, combinational test case generation should achieve as much code coverage as possible. I use http://www.testersdesk.com to generate pair/3way/4way/5way and n way test cases. Always go with 'n way' since that way you will test 100% of the code. The website has many other useful tools. You need to register to use their tools, all of which are free. And there is also an option to download the test cases as csv for data-driven testing. Hope this helps.

  6. you have mentioned very useful steps for designing a test case.It is really a fantastic post.

  7. Hi Inder, Good post. Actually we are using this kind of design and we are succesful in our automation of major projects.

    Best regards,
    Madhusudan Ganda

  8. thank you for the professional instructions you gave us this article. keep posting articles in this subject please. thanks!