Enablement tests ensure that the English product can function on the native OS using DBCS chars, BIDI chars, etc. The test cases are usually a small subset of the functionality test cases, but enablement test cases are geared toward verifying that the code can make a round trip without corruption between the country input chars and the country output chars. Enablement tests include Locale support, for example a date or time format is different between America and France, and would need to be displayed differently in the UI. Enablement tests check both the UI and any non-UI component that displays Locale-sensitive data.

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.

1. 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.
2. 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
3. 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).
4. 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.
5. Provide the tests in DOC format if possible, or a zip containing a single HTML file with the image files.

1. Don't include any screen in a test if that screen hasn't changed since the last release.
2. Don't provide a document that has no divider or numbering scheme to identify where one test case begins and another test case ends.

When completed, check in the new test case as explained in this document.