A short guide for rewriting test cases

Currently, all test cases used in various testing activities (for example ISO testing) are kept in the wiki. After careful assessment we have determined that they are not fit for purpose, for most of them two people running the same test case would come up with different results and this is not desirable. We need to convert them to unambiguous and meaningful test cases, following the template agreed. Some of them are redundant, some of them are testing too many conditions to be just one test case, some others are obsolete. This is a tidy up task that needs to be done.

While working on a rewrite, please use our Google Docs Document and follow this guide:

1. Find a test case in the wiki that you would like to rewrite. Make sure that noone else is working on it by searching the TestID column on the spreadsheet. When you've verified that, write its ID in the TestID column.

2. Write a test category in the Category column. For example, if rewriting test cases for ISO installation, use Installation category. If in doubt, you can check the category by looking at the wiki's URL of the test case.

3. Write a brief test description in the Description column. You should explain the main purpose of this test.

4. If there are prerequisites for running the test case, write them down in the Assumptions column. So for instance if the test case assumes that certain software not available on a default installation is installed on the machine prior to running the test case, please say so.

5. Now read the test case as attentively as possible. Do one of the following:
   

   1. If the test case is not relevant for current systems, do not rewrite it. Add the test case ID to the spreadsheet and mark it as Obsolete in the Review Status column, give a reason in the Review Answers column.

   2. If all the steps are clearly understandable, and it is explained how to verify them - write them down accordingly in Actions/Expected Results columns.

   3. If you believe that the test case is duplicate of another case, write the number of that other case in Actions like this: "DUPLICATE OF <that other case ID>".

   4. If the test case is too complex or too long - split it to 2 different test cases. Use -1, -2, etc. notation for ID numbers of all such cases.

   5. If the actions are not properly explained - rewrite them to be more accurate and write them down in the Actions column.

   6. If the "expected results" are not provided fully in the original test case, or are ambiguous - rewrite them to comply with actions and write them down in the Expected Results column.

6. If you know whether the test case is going to be automated or manual, write that down in Auto/Manual? column. Otherwise, leave it empty.

7. Write your email or Launchpad ID in Author Details column.

8. If the test case supposed to test a specific package, write down its name in Packages Affected column. Otherwise, leave it empty.

9. In Review Status column add FOR REVIEW, and someone will look at it and review your work.

10. Send an email to ubuntu-qa@lists.ubuntu.com asking for a review of your test cases, stating their TestIDs.

11. After you get some comments, modify the test cases accordingly if you consider the comments are fair and make sense. You can ignore comments if you see that is best, by giving an explanation in the Review Answers column.

12. Then update the wiki with the new test case once it is complete.

That would be it! Thanks for the great job making Ubuntu better!