/ directory. * This directory is obsolete now. It serves as source for localization contributors only. * * ----------------------------------------------------------------------------------- */ // printFilter.html $TLS_hlp_generateDocOptions = "

Options for a generated document

This table allows the user to filter test cases before they are viewed. If selected (checked) the data will be shown. In order to change the data presented, check or uncheck, click on Filter, and select the desired data level from the tree.

Document Header: Users can filter out Document Header information. Document Header information includes: Introduction, Scope, References, Test Methodology, and Test Limitations.

Test Case Body: Users can filter out Test Case Body information. Test Case Body information includes: Summary, Steps, Expected Results, and Keywords.

Test Case Summary: Users can filter out Test Case Summary information from the Test Case Title, however, they cannot filter out Test Case Summary information from the Test Case Body. Test Case Summary has only been partially separated from Test Case Body in order to support viewing Titles with a brief Summary and the absence of Steps, Expected Results, and Keywords. If a user decides to view Test Case Body, Test Case Summary will always be included.

Table of Content: TestLink inserts list of all titles with internal hypertext links if checked.

Output format: There are two possibilities: HTML and MS Word. Browser calls MS word component in second case.

"; // testPlan.html $TLS_hlp_testPlan = "

Test Plan

General

A test plan is a systematic approach to testing a system such as software. You can organize testing activity with particular builds of product in time and trace results.

Test Execution

This section is where users can execute test cases (write test results) and print Test case suite of the Test Plan. This section is where users can track the results of their test case execution.

Test Plan Management

This section, which is only lead accessible, allows users to administrate test plans. Administering test plans involves creating/editing/deleting plans, adding/editing/deleting/updating test cases in plans, creating builds as well as defining who can see which plan.
Users with lead permissions may also set the priority/risk and ownership of Test case suites (categories) and create testing milestones.

Note: It is possible that users may not see a dropdown containing any Test plans. In this situation all links (except lead enabled ones) will be unlinked. If you are in this situation you must contact a lead or admin to grant you the proper project rights or create a Test Plan for you.

"; // custom_fields.html $TLS_hlp_customFields = "

Custom Fields

Following are some facts about the implementation of custom fields:

Custom fields are defined system wide.
Custom fields are linked to a type of element (Test Suite, Test Case)
Custom fields can be linked to multiple Test Projects.
The sequence of displaying custom fields can be different per Test Project.
Custom fields can be turned inactive for an specific Test Project.
Number of custom fields is not restricted.

The definition of a custom field includes the following logical attributes:

Custom field name
Caption variable name (eg: This is the value that is supplied to lang_get() API , or displayed as-is if not found in language file).
Custom field type (string, numeric, float, enum, email)
Enumeration possible values (eg: RED|YELLOW|BLUE), applicable to list, multiselection list and combo types.
Use the pipe ('|') character to separate possible values for an enumeration. One of the possible values can be an empty string.
Default value: NOT IMPLEMENTED YET
Minimum/maximum length for the custom field value (use 0 to disable). (NOT IMPLEMENTED YET)
Regular expression to use for validating user input (use ereg() syntax). (NOT IMPLEMENTED YET)
All custom fields are currently saved to a field of type VARCHAR(255) in the database.
Display on test specification.
Enable on test specification. User can change the value during Test Case Specification Design
Display on test execution.
Enable on test execution. User can change the value during Test Case execution
Display on test plan design.
Enable on test plan design. User can change the value during Test Plan design (add test cases to test plan)
Available for. User choose to what kind of item the field belows.

"; // execMain.html $TLS_hlp_executeMain = "

Executing Test Cases

Allows users to 'execute' test cases. Execution itself is merely assigning a test case a result (pass,fail,blocked) against a selected build.

Access to a bug tracking system could be configured. User can directly add a new bugs and browse exesting ones then.

"; //bug_add.html $TLS_hlp_btsIntegration = "

Add Bugs to Test Case

(only if it is configured) TestLink has a very simple integration with Bug Tracking Systems (BTS), not being able either send a bug creationg request to BTS, neither get back the bug id. The integration is done using links to pages on BTS, that calls the following features:

Insert new bug.
Display existent bug info.

Process to add a bug

Step 1: use the link to open BTS to insert a new bug.
Step 2: write down the BUGID assigned by BTS.
Step 3: write BUGID on the input field.
Step 4: use add bug button.

After closing the add bug page, you will see relevant bug data on the execute page.

"; // execFilter.html $TLS_hlp_executeFilter = "

Setup Filter and Build for test execution

The left pane consists from navigator through test cases assigned to the current " . "Test plan and table with settings and filter. These filters allows the user " . "to refine offered set of test cases before they are executed." . "Setup your filter, press the \"Apply\" button and select appropriate Test Case " . "from tree menu.

Build

Users must choose a build that will be connected with a test result. " . "Builds are the basic component for the current Test Plan. Each test case " . "may be run more times per build. However the last results is count only.
Builds can be created by leads using the Create New Build page.

Test Case ID filter

Users can filter test cases by unique identifier. This ID is created automatically during create time. Empty box means that the filter doesn't apply.

Priority filter

Users can filter test cases by test priority. Each test case importance is combined" . "with test urgency within the current Test plan. For example 'HIGH' priority test case " . "is shown if importance or urgency is HIGH and second attribute is at least MEDIUM level.

Result filter

Users can filter test cases by results. Results are what happened to that test case during a particular build. Test cases can pass, fail, be blocked, or not be run." . "This filter is disabled by default.

User filter

Users can filter test cases by their assignee. The check-box allows to include also " . "\"unassigned\" tests into the resulted set in addtion.

"; /*

Most Current Result

By default or if the 'most current' checkbox is unchecked, the tree will be sorted by the build that is chosen from the dropdown box. In this state the tree will display the test cases status.
Example: User selects build 2 from the dropdown box and doesn't check the 'most current' checkbox. All test cases will be shown with their status from build 2. So, if test case 1 passed in build 2 it will be colored green.
If the user decideds to check the 'most current' checkbox the tree will be colored by the test cases most recent result.
Ex: User selects build 2 from the dropdown box and this time checks the 'most current' checkbox. All test cases will be shown with most current status. So, if test case 1 passed in build 3, even though the user has also selected build 2, it will be colored green.

*/ // newest_tcversions.html $TLS_hlp_planTcModified = "

Newest versions of linked Test Cases

The whole set of Test Cases linked to Test Plan is analyzed, and a list of Test Cases which have a newest version is displayed (against the current set of the Test Plan).

"; // requirementsCoverage.html $TLS_hlp_requirementsCoverage = "

Requirements Coverage

This feature allows to map a coverage of user or system requirements by test cases. Navigate via link \"Requirement Specification\" in main screen.

Requirements Specification

Requirements are grouped by 'Requirements Specification' document which is related to Test Project.
TestLink doesn't support versions for both Requirements Specification and Requirements itself. So, version of document should be added after a Specification Title. An user can add simple description or notes to Scope field.

Overwritten count of REQs serves for evaluation Req. coverage in case that not all requirements are added (imported) in. The value 0 means that current count of requirements is used for metrics.

E.g. SRS includes 200 requirements but only 50 are added in TestLink. Test coverage is 25% (if all these added requirements will be tested).

Requirements

Click on title of a created Requirements Specification. You can create, edit, delete or import requirements for the document. Each requirement has title, scope and status. Status should be \"Normal\" or \"Not testable\". Not testable requirements are not counted to metrics. This parameter should be used for both unimplemented features and wrong designed requirements.

You can create new test cases for requirements by using multi action with checked requirements within the specification screen. These Test Cases are created into Test Suite with name defined in configuration (default is: $tlCfg->req_cfg->default_testsuite_name = \"Test suite created by Requirement - Auto\";). Title and Scope are copied to these Test cases.

"; // planAddTC_m1.tpl $TLS_hlp_planAddTC = "

Regarding 'Save Custom Fields'

If you have defined and assigned to Test Project,
Custom Fields with:
'Display on test plan design=true' and
'Enable on test plan design=true'
you will see these in this page ONLY for Test Cases linked to Test Plan. "; // xxx.html //$TLS_hlp_xxx = ""; // ----- END ------------------------------------------------------------------ ?>