Process documentation
Guidelines for writing a Translation Verification Test Case

Translation tests verify the translation for context accuracy. These tests ensure that the function does not appear in English, that the translation is displayed correctly, and that the translation itself is correct. Translation tests check both the UI and any non-UI component that displays Locale-sensitive data.

When writing translation verification test cases ("TVT"), assume that you are dealing with someone who has never seen the product before and is not a technical person.

  1. Provide delta test cases instead of a full set. Unlike regression testing, TVT 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, TVT.BugzillaComponentId.number - English title, e.g. TVT.Monitor.Agents.1 - Main Window
  3. Test only one screen in each test case, and put detailed step-by-step instructions on how to get to that screen. For example, if a wizard has several pages, instead of testing the entire wizard in a single test case, split that test into one test case for each page. Do not put in additional screen captures to aid the testers with navigation because they won't be used for navigation; instead, testers test any screen capture that they see.
  4. When providing screen captures, ensure the testers can easily identify the content to be tested. If all of the content in the screen capture is not tested, enclose the content to be tested with a red outline (for example, square or circle).
  5. Make each test stand-alone, meaning that you don't have to depend on the previous test to run this test. Testers should be able to run the test cases in any order.
  6. 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 use tutorials as TVT.
  3. Don't write a test case that verifies the function rather than the screens; function verification is done in the enablement test cases.
  4. Don't provide a document that has no divider or numbering scheme to identify where one test case begins and another test case ends.
This example demonstrates the preferred format for the TVT test cases.

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