Test Design Guidelines for reusability

Last updated:jan.10.2008

From:http://safsdev.sourceforge.net/sqabasic2000/testdesignguidelines.htm

• Purpose
• APP Map and Test Table UTF-8 File Encodings
• APP Map Chaining
• APP Map Resolving Embedded Variables
• Designing Tests for NLS
• A Complete Dynamic Text Example support NLS

Purpose

This document provides a set of guidelines. Enable a tester to plan the development of test designs and related assets To maximize reuse. The intended context for this reuse are to maximize the potential for effective system\application configuration testing an D localization testing, also known as NLS testing. Throughout this document we'll refer primarily to NLS testing, but the concepts apply equally well to configuration test ing and other forms of testing requiring reconfigurable text values.

The app map features referenced here as App Map Chaining and app map resolving Embedded Variables is only available in VE Rsions of SAFS dated on or after 2006.

It's important to recognize, the single most important notion for making test designs reusable for NLS and Configurat Ion testing is this no localizable or configuration-specific text must exist in the test designs or test actions--the test Tables. All such text must is managed in separate text resource files, which in the SAFS world means separate App Maps. The test designs and test actions would reference the text via variable references which would be retrieved from the APP Map s opened for the target language or configuration.

App Map and Test Table UTF-8 File encodings

(need to respecify the following statement based in most recent experiences with rational Robot and rational Functiona L Tester evaluations.)

In order to properly represent mixed character data (some single-byte and some multi-byte) the UTF-8 character encoding fo Rmat is supported by Rrafs and SAFS. All apps Maps and Test Tables intended to being used for NLS testing should is encoded in the proper format required by the OLS in use.

App Map Chaining

Note:app Map Chaining By default was not enabled in order to maintain backwards compatibility with existing tests. You must use the ' appmapchaining ' Driver Command to enable this feature.

C, Appmapchaining, on

App Map Chaining is the process by which multiple App Maps can opened and searched for referenced values. APP Maps opened with chaining enabled is searched in Last-in-first-out (LIFO) Order. This allows the opening of scenario-specific maps--language or configuration, Etc.--to is opened in addition to generic an D shared maps. Maps opened later can has the values that override or Supercede maps opened earlier. In addition, GKFX maps can contain embedded variables (see below) that can is satisfied by the scenario-specific maps. For example, a shared map could reference an embedded variable containing localizable text that would be found in another ope n App map--the One specific to the language being tested.

Example:

C, Setapplicationmap, FMSTUDIO_NLSC, Setapplicationmap, Fmstudio_map

This design snippet shows, being opened. The first opened map (FMSTUDIO_NLS) would contain the localized text specific to the language being tested. All entries in this map would is in the default [applicationconstants] sections so, they could be retrieved as variable S. The second map (FMSTUDIO_MAP) would is the shared map used in all testing no matter what the language or configuration. The entries in this shared map would contain embedded variables whose values would is found in the localized map. Since the maps is read in LIFO order due to App Map Chaining, values would first be sought in the fmstudio_map. Embedded variables or other values is satisfied by, that map would then be sought in the Fmstudio_nls map.

App Map resolving Embedded Variables

note:resolving embedded variables in App Maps are not enabled by default in order to maintain backwards compatibility with Existing tests. You must use the ' appmapresolve ' Driver Command to enable this feature.

C, Appmapresolve, on

An APP Map entry can contain references to variables whose values would be resolved to complete the entry. See Resolving Ddvariables for Dynamic recognition For more information on this capability. Essentially, the idea-to keep-is-that-the-shared maps would contain largely static text that does not need to be lo Calized or changed for subsequent testing. Where some portion of an APP maps entry does need to contain localized text that portion'll be represented as an embedded Variable and the ultimate value of that variable'll be retrieved from a locale-specific App Map that's opened in Addit Ion to the shared App Map.

Example:

fmstudio_nls_en (known as FMSTUDIO_NLS):---------------------------------------- [applicationconstants]nlshello= "Hello!" Fmstudio_nls_es (known as FMSTUDIO_NLS):---------------------------------------- [applicationconstants]nlshello= "¡hola!" Fmstudio_map:------------- Hellolink= "Type=htmllink; Htmltext={^nlshello} "

Now, let us assume that the test was run first in 中文版 and then later in Spanish. The first time the test is run the Fmstudio_nls_en (中文版) map is loaded along with the Fmstudio_map. When the test goes to retrieve the value for the Hellolink component it'll find the embedded ^nlshello variable Referenc E which must be retrieved. The ^nlshello variable does not exist in the shared map so App map Chaining would go look for the value in the 中文版 map. The value retrieved for ^nlshello is "hello!" and the resulting Hellolink value would be:

Hellolink= "Type=htmllink; Htmltext=hello! "

The second time the test is run the Fmstudio_nls_es Spanish map is loaded along with the Fmstudio_map. This time the value retrieved-^nlshello is "¡hola!" and the resulting Hellolink value would be:

Hellolink= "Type=htmllink; htmltext=¡hola! "

As can see, App Map Chaining with Embedded Variables are a powerful combination that enables us to deliver tests that C An readily is migrated for NLS testing. However, to accomplish this it requires the Test designers to design the tests and these assets with the goal of NLS reuse in mind.

designing Tests for NLS and other Forms of reuse

Just as special design consideration must be given during software development to make a application support Internati Onalization, Localization, and globalization, so too must we test designs receive this same level of design consideration . If The tests is not designed from the very beginning with this goal on mind then the process of going back and making the Tests Nls-ready can be very difficult and time consuming.

The APP Map processing features mentioned above allow us to use the same common practice used by software developers WH En developing software. That's, we must design our tests for NLS by separating textual data and other environment-dependent resources out of the Tests themselves and into separate resource files. This means we want all environment-dependent the text stored in environment-specific App Maps. Other environment-dependent resources like image files should is referenced through environment-specific entries in those Same App Maps. In this, the tests themselves does not change No. matter which environment is being tested. When we go to test in a new environment we just make sure we use the appropriate App Map (s) and resources targetted for th At environment.

It takes vigilance and attentive awareness to design a test, which is truly nls-ready. All environment-specific text and resources must is kept out of the design and moved into the resource files (App Maps). The designs would merely contain variable references that would ultimately be satisfied by lookups into the Environment-spec Ific App Maps. This isn't only includes language-specific text, might appear in object recognition strings, but also any language-speci FIC string that might is evaluated or Verified--such as an object property value, displayed text, or image benchmarks whos E image may contain environment-specific text, legends, or formats.

An example of might is a Label on a dialog box that informs the user that a certain process either succeeded or faile D. The recognition string for the label is require special handling as its Name or ID is common across all enviro Nments as shown below:

Statuslabel= "Type=label; Name=lblstatus "

However, when we wish to verify the status displayed to the user in the the Label we is going to is dealing with literal text That would likely be localized and needs to be stored separately in our NLS resource files or App Maps.

Problem:

T, Statusdialog, Statuslabel, Verifyproperty, "Text", "success!"

Solution:

T, Statusdialog, Statuslabel, Verifyproperty, "Text", ^nlssuccess

To make sure our tests is Nls-ready we is tasked to verify a few things:

1. The Name of the "does not" in the "environments" so it does not need to be localized.
2. The name of the Text property does is not a change in other environments so it does not need to be localized.
3. The displayed text in the Label would change in other environments so it does need to be localized.

Thus, our Nls-ready App Maps need-to-hold this localizable text so, the proper values is found at runtime:

fmstudio_nls_en (known as FMSTUDIO_NLS):---------------------------------------- [applicationconstants]nlshello= "Hello!" Nlssuccess= "Success!" Nlsfailed= "failed!" Fmstudio_nls_es (known as FMSTUDIO_NLS):---------------------------------------- [applicationconstants]nlshello= "¡hola!" Nlssuccess= "¡éxito!" Nlsfailed= "¡fallado!"

As you can see, it takes special attention and vigilance to carefully design we tests so that they is nls-ready! The same level of care must is taken for all forms of displayed text, text to is input from the user this might be LANGUAG E-specific, and other resources containing environment-specific data like locale-specific currency, time, and date formats .

A Complete Dynamic Text Example supporting NLS

The Scenario:

You wish to create a highly reusable step table (action) that would close any window in your application and then check the Application state. We ll call the " closeappwindow" table.

This can serve a number of purposes, including:

• High value test assets with reduced maintenance
• Supports dynamic features of the AUT
• Supports growing automated coverage of the AUT
• Existing automated tests is suitable for NLS testing

The problem: For maximum reusability, Closeappwindow must is able to recognize different windows according to their Any-langua GE Caption, so no part of Closeappwindow, orany of the tables that call it, can contain Langua Ge-specific text.

The solution: Use app map Chaining, app map Embedded Variables, and application Constants.

1. A Few examples calling Closeappwindow with the Caption parameter using application Constants :

T Closeappwindow ^caption=^reportscaption t Closeappwindow ^caption=^helpcaption

T Closeappwindow ^caption=^aboutcaption There is no localizable text calling Closeappwindow

.

2. the implementation of the Closeappwindow Step table:

T anywindow anywindow closewindow... followed by important status and error checks there isno localizabl e text in Closeappwindow.

3. The Primary app map using app map Embedded Variables:

Myapp.map:----------... [Anywindow] Anywindow= "Type=window; Caption={^caption} "... There is no localizable text in the primary App Map.

4. The NLS app maps for app Map Chaining for application Constants:

myapp_nls_en (known as MYAPP_NLS):--------------------------------------[applicationconstants]reportscaption= "Reports" Helpcaption= ' help ' aboutcaption= ' about ' alllocalizable text is confined to the NLS App Map. Myapp_nls_es (known as MYAPP_NLS):--------------------------------------[applicationconstants]reportscaption= "Informes" helpcaption= "Ayuda" aboutcaption= "Sobre"

This sample design shows maximum reusability. The same test used to automatically test the Chinese translation of the application can be used to test all other Localiza tions. And the amount of localization necessary for each translation have been minimized to a single NLS App Map file.

Test Design Guidelines for reusability