Background

TVT cases are used to test the translation of any string changes (additions or modifications) in the ETM web UI.

Typically, 80% of the TVT cases are due one week before UI freeze and the remaining 20% of the TVT cases are due at UI freeze.

TVT cases are executed by the Test Verification Testers on Windows 7 and zOS/Power system OS for some components.

Developer Steps

1. Tag all the work items that are delivered with string changes (additions or modifications) in the current release (see Finding TVT Work Items) with the tvt<current release version> tag (for example, tvt605). If the work items that are delivered with string changes (additions or modifications) in the current release but do not require TVT cases, tag them with tvt_exclude tag. See Tips for Creating TVT Cases to determine what can be excluded. For more information, see Work Item Tags. Note: As of ETM 7.0.2, use the Translation work item property (required when resolving a work item).
2. Determine the work items that you own and require TVT cases (see ETM TVT Work Items Query).
3. For each work item that requires TVT cases, create new TVT cases that cover the functional area. Name must start with TVT - and the required test case categories, for example, TVT - Test relevant team members while assigning owner of an artifact. Also, select the fields under the categories, Application = QM, Test Type = TVT, and Component = <UI functional component>). UI functional component is basically which menu option in the application do you start with. There are QM_Preferences and QM_Administration components for the action icons in the menu bar. The components are used only to help grouping of the test cases, do not worry if it is not the right component.
4. If there is an existing TVT case that covers the functional area (see ETM TVT Cases) are found, instead of modifying the TVT case, make a copy (see Tips for Creating TVT Cases). To find the existing TVT cases that cover the functional area, search the existing TVT cases by Name, follow the Related Test Case or Tested By Test Case links associated with the work items.
5. Link the TVT cases to the work items by using the Tested By Test Case link.
6. Add the TVT cases to the TVT plan named RQM TVT - <current release version> (see ETM TVT Plans).
7. Add a new Review request (see the Formal Review section of the test case editor) to the TVT cases for Paulus Chu to review. Change the state of the TVT Cases to Under Review.
8. Once the TVT cases are reviewed, tag all work items that are delivered the string changes (additions or modifications) in the current release with the tvt<current release version>_complete tag (for example, tvt605_complete). For more information, see Work Item Tags. Note: As of ETM 7.0.2, use the Translation work item property (required when resolving a work item).

Tips for Creating TVT Cases

Following are the few tips for authoring TVT test case:

1. A TVT case has instructions on how to get to a particular screen for a TVT tester who might not know anything about ETM. The screen capture should have a red color outline around the string changes (additions or modifications).
2. Be clear with the instructions and do not give open-ended options. For example, do not use "create a few test cases", "type something for the name", or "the test case created in previous step". Instead, use "create 2 test cases", "enter 'my case 1' and 'my case 2' for the name", or "the test case 'my case 2'".
3. Be clear with the action, usually the execution step is "Verify the message in the red box". Execution actions like "you see a message...", "make sure the message... appear" and "observe the message displayed", are more for function testing. For TVT, they are information steps not execution steps.
4. It is useful to add screen captures with color outline to guide where to click. Use blue or green color other than red color. It can be confusing with all screen captures with red color outline. Use red color, only for the messages that need to be verified.
5. If you are reusing an existing TVT case, make a copy of the TVT case and remove the steps that verify strings that are already covered in the previous TVT. Do not modify the existing TVT case. A new language can be added specifically for an earlier release. You need the TVT cases for that release not just the latest.
6. During test verification testing, the JKE Banking sample is always installed. Use the sample data in the JKE Banking sample, referencing the sample data by name. If any custom data is required, include a setup step for the TVT support team to pre-create the custom data as prerequisite.
7. Use the easiest way to display screens containing the string changes (additions or modifications). For example, an FVT case might include setting a project property, creating a test script, test case, and test plan, then running the test case to generate a test case result. A TVT case contains a prerequisite setup step to pre-create a test case result for the TVT support team, and another execution step to the tester to open the test case result (Select Execution >> Browse >> Test Case Results >> <test case result name>).
8. If displaying one or more screens that contain the string changes (additions or modifications) is too complicated for the tester (not for the developer), create a screen capture TVT case that contains screen captures of one or more screens for all supported locales including English (see Supported Locales). The TVT case contains a test script with a single step of the description and screen capture of the screens that are used in ETM. The developer attaches the translated screen captures when you have all the translation that is returned and incorporated into a build. The UI functional component should be "PII Validation", and the test case should have a prefix "Screenshot TVT".
9. The same message that is used in multiple places in the same context, needs to be verified once only, such as an error message that is used in the editor page header can also be used in an error dialog. However, if the same label is used in different contexts, you need to verify it in all the different context. For example, a label for a button label can also be used as a tooltip and as a dialog title. Some languages have different translation between the verb form versus the noun form.

Exceptions for Creating TVT Cases

Following are the exceptions for the message changes that do not require TVT cases:

1. Log and error messages that are not displayed in the web UI.
2. Messages for command-line tools. The tools are intended for admin and support not regular users with the web UI.
3. Messages that are hard to get to, even for the developer. For example, an options dialog when connection to a test adapter is dropped. You can't have a step to unplug the cable. For that, add a comment in the messages file explaining where the string is used and what are the string values can be if there are variables in the string (for example, %1 = test plan or test case).
4. Well-known labels that are used in other places in the same way, such as the label of a name-value pair "Iteration:", "Test Environment:". It might be a new dialog, but those name-value pairs are common in the artifact editors.
5. String changes to fix typos or grammatical mistakes (e.g. add the article the), where changing the wording does not change the meaning and usage of the strings.
6. String changes that change the case of words.

ETM TVT Work Items Query

1. ETM TVT Work Items Query

ETM TVT Plans

ETM TVT Plans >> ETM TVT - <current release version>

ETM TVT Cases

ETM TVT Cases

Supported Locales

The supported locales are organized into three groups:

NL1

• de
• en
• es
• fr
• it
• ja
• ko
• pt-br
• zh
• zh-hk
• zh-tw

NL2

• cs
• hu
• pl
• ru

NL2a

• tr

Pseudo Testing

Pseudo translation is the way to test translation without waiting for the actual translation from all other countries. It uses a couple of made-up locales in English (en-AA and en-ZZ) that generated the pseudo translated strings during the build. Setting the browser to one of these locales has all externalized strings display pseudo translated. RelEng is responsible to enable the pseudo translation in the build. The pseudo translation testing is part of the GVT to ensure that all strings are externalized especially the new and changed strings for TVT. This is to catch any layout issue or strings that are not externalized before the TVT.

The en-ZZ pseudo translated strings have a specific prefix ([G') and a suffix (ฏูİı｜]) such as "[G'M o re...ฏูİı｜]". The angle brackets help identifying nested strings. If a string does not have these angle brackets, then the string is not externalized. Each string is padded with extra blank spaces and some characters are in double-byte. That is to simulate the translated strings in other languages that are much longer than English such as German and Russian.

For en-AA, each string has the unique ID as suffix (~<bundle id><string id>) such as "More...~ETM-AB209" with bundle id ETM-AB2 and string id 09. In each translated bundle, there is a mapping file (<bundle id>)TVT_Map_build<date>.txt such as (ETM-AB)TVT_Map_build20200803.txt. The bundle ID in the file name is the bundle ID in the en-AA translated string. With the mapping file, you can identify exactly which bundle and message ID of a translated string. The translated bundles and the mapping file are in the pseudo_main compressed file (.zip file) of the build components in the build result page. In the Download NLS Zips link of the build result page, there is a maps directory that contains the files of all bundle ids and the corresponding plug-ins.

Finding TVT Work Items

To find all work items that delivered string changes (additions or modifications) in the current release, the Rational Team Concert Eclipse client, select Search >> Jazz Source Control >> Change Sets...>):

Note: The Created after date is the start date of M0 (or M1) sprint for the release. For more information, see Rational Quality Manager Timelines).

Contacts

• Paulus Chu