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 = "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.
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.
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 = "Following are some facts about the implementation of custom fields:
The definition of a custom field includes the following logical attributes:
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 existing ones then. See Installation manual for more.
"; //bug_add.html $TLS_hlp_btsIntegration = "(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:
Settings allows you to select the test plan, build and platform (if available) to be executed.
You can choose the required test plan. According to the chosen test plan the appropriate builds will be shown. After choosing a test plan filters will be reset.
If the platforms feature is used, you must select the appropriate platform before execution.
You can choose the build you whish to execute the test cases for.
Filters provide the opportunity to further influence the set of shown test cases before the execution. You can reduce the set of shown test cases by specifying filters and click the \"Apply\" button.
Advanced Filters will allow you to specify a set of values for applicable filters by using CTRL-Click inside the Multi-Select ListBox
You can filter test cases by the keywords that have been assigned. You can choose " . "multiple keywords by using CTRL-Click. If you chose more than one keyword you can " . "decide whether only test cases are shown that have all chosen keywords assigned " . "(radiobutton \"And\") or at least one of the chosen keywords (radiobutton \"Or\").
You can filter test cases by test priority. The test priority is \"test case importance\" " . "combined with \"test urgency\" within the current test plan.
You can filter test cases that are not assigned (\"Nobody\") or assigned to \"Somebody\". " . "You can also filter test cases that are assigned to a specific tester. If you chose a specific " . "tester you also have the possibility to show test cases that are unassigned in addition to " . "those test cases (advanced Filters are available).
You can filter test cases by result (advanced Filters are available). You can filter by " . "result \"on chosen build for execution\", \"on latest execution\", \"on ALL builds\", " . "\"on ANY build\" and \"on specific build\". If \"specific build\" is chosen you then can " . "specify the build.
"; // newest_tcversions.html $TLS_hlp_planTcModified = "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 = "This feature allows to map a coverage of user or system requirements by test cases. Navigate via link \"Requirement Specification\" in main screen.
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).
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.
"; $TLS_hlp_req_coverage_table = "Internal links serve the purpose of creating links to other requirements/requirement specifications
with a special syntax. Internal Links behaviour can be changed in the config file.
Usage:
Link to requirements: [req]req_doc_id[/req]
Link to requirement specifications: [req_spec]req_spec_doc_id[/req_spec]
The test project of the requirement / requirement specification, a version and an anchor
to jump to can also be specified:
[req tproj=<tproj_prefix> anchor=<anchor_name> version=<version_number>]req_doc_id[/req]
This syntax also works for requirement specifications (version attribute has no effect).
If you do not specify a version the whole requirement including all versions will be shown.
Whenever a change is made Testlink will ask for a log message. This log message served the purpose of traceability. If only the scope of the requirement has changed you are free to decide whether to create a new revision or not. Whenever anything besides the scope is changed you are forced to create a new revision.
"; // req_view $TLS_hlp_req_view = "To easily share this document with others simply click the globe icon at the top of this document to create a direct link.
This feature allows to compare revisions/versions of requirements if more than one revision/version of the requirement exists. The overview provides the Log message for each revision/version, a timestamp and the author of the last change.
Shows all linked test cases for this requirement.
Requirement Relations are used to model relationships between requirements. Custom relations and the option to allow relations between requirements of different test projects can be configured on the config file. If you set the relation \"Requirement A is parent of Requirement B\", Testlink will set the relation \"Requirement B is child of Requirement A\" implicitly.
"; // req_spec_edit $TLS_hlp_req_spec_edit = "Internal links serve the purpose of creating links to other requirements/requirement specifications
with a special syntax. Internal Links behaviour can be changed in the config file.
Usage:
Link to requirements: [req]req_doc_id[/req]
Link to requirement specifications: [req_spec]req_spec_doc_id[/req_spec]
The test project of the requirement / requirement specification, a version and an anchor
to jump to can also be specified:
[req tproj=<tproj_prefix> anchor=<anchor_name> version=<version_number>]req_doc_id[/req]
This syntax also works for requirement specifications (version attribute has no effect).
If you do not specify a version the whole requirement including all versions will be shown.