When writing enablement test cases, assume that you are dealing with someone who is not necessarily familiar with the product but has some technical knowledge.
- Provide delta test cases instead of a full set. Unlike regression testing, enablement testers test only the screens that have changed since the previous release. That is, if the function existed in a prior version of TPTP that was translated, then do not include it again. If the function was in a prior version of TPTP, but that version was not translated, then do include a test case for the function.
- Assign a unique number to each test case because that simplifies tracking. Each test case name must be unique in the entire TPTP bucket; e.g., a test case name from one team should not be the same as a test case name from another team. Follow this naming convention, Enablement.BugzillaComponentId.number - English title, e.g. Enablement.Monitor.Agents.1 - Main Window
- When providing screen captures, ensure the testers can easily identify the content associated with the test case. If the content associated with the test case is not obvious, enclose the relevant content with a red outline (for example, square or circle).
- Write a tutorial for a test case if time permits. Because enablement test cases test function, not translation per se, we can reuse the tutorials to show people how to use the new function.
- Provide the tests in DOC format if possible, or a zip containing a single HTML file with the image files.
- Don't include any screen in a test if that screen hasn't changed since the last release.
- Don't provide a document that has no divider or numbering scheme to identify where one test case begins and another test case ends.
CVSWhen completed, check in the new test case as explained in this document.