] and $TLS_help_title[] * or * $TLS_instruct[] and $TLS_instruct_title[] * * * Revisions history is not stored for the file * * ------------------------------------------------------------------------------------ */ $TLS_htmltext_title['assignReqs'] = "Assign Requirements to Test Case"; $TLS_htmltext['assignReqs'] = "

Purpose:

Users can set relations between requirements and test cases. A designer could define relations 0..n to 0..n. I.e. One test case could be assigned to none, one or more test cases and vice versa. Such traceability matrix helps to investigate test coverage of requirements and find out which ones successfully failed during a testing. This analyse serves as input for the next planning.

Get Started:

  1. Choose an Test Case in tree at the left. The combo box with list of Requirements Specifications is shown at the top of workarea.
  2. Choose a Requirements Specification Document if more once defined. TestLink automatically reload the page.
  3. A middle block of workarea lists all requirements (from choosen Specification), which are connected with the test case. Bottom block 'Available Requirements' lists all requirements which have not relation to the current test case. A designer could mark requirements which are covered by this test case and then click the button 'Assign'. These new assigned test case are shown in the middle block 'Assigned Requirements'.
"; // -------------------------------------------------------------------------------------- $TLS_htmltext_title['editTc'] = "Test Specification"; $TLS_htmltext['editTc'] = "

Purpose:

Purpose:

The Test Specification allows users to view and edit all of the existing " . "Test Suites and Test Cases. Test Cases are versioned and all " . "of the previous versions are available and can be viewed and managed here.

Getting Started:

  1. Select your Test Project in the navigation tree (the root node). Please note: " . "You can always change the activate Test Project by selecting a different one from the " . "drop-down list in the top-right corner.
  2. Create a new Test Suite by clicking on New Child Test Suite. Test Suites can " . "bring structure to your test documents according to your conventions (functional/non-functional " . "tests, product components or features, change requests, etc.). The description of " . "a Test Suite could hold the scope of the included test cases, default configuration, " . "links to relevant documents, limitations and other useful information. In general, " . "all annotations that are common to the Child Test Cases. Test Suites follow " . "the "folder" metaphor, thus users can move and copy Test Suites within " . "the Test project. Also, they can be imported or exported (including the contained Test cases).
  3. Test suites are scalable folders. User can move or copy Test Suites within " . "the Test project. Test suites could be imported or exported (include Test cases).
  4. Select your newly created Test Suite in the navigation tree and create " . "a new Test Case by clicking on Create Test Case. A Test Case specifies " . "a particular testing scenario, expected results and custom fields defined " . "in the Test Project (refer to the user manual for more information). It is also possible " . "to assign keywords for improved traceability.
  5. Navigate via the tree view on the left side and edit data. Test cases stores own history.
  6. Assign your created Test Specification to Test Plan when your Test cases are ready.

With TestLink you organize test cases into test suites." . "Test suites can be nested within other test suites, enabling you to create hierarchies of test suites. You can then print this information together with the test cases.

"; // ------------------------------------------------------------------------------------------ $TLS_htmltext_title['searchTc'] = "Test Case Search Page"; $TLS_htmltext['searchTc'] = "

Purpose:

Navigation according to keywords and/or searched strings. The search is not case sensitive. Result include just test cases from actual Test Project.

To search:

  1. Write searched string to an appropriate box. Left blank unused fields in form.
  2. Choose required keyword or left value 'Not applied'.
  3. Click the Search button.
  4. All fulfilled test cases are shown. You can modify test cases via 'Title' link.
"; // ------------------------------------------------------------------------------------------ $TLS_htmltext_title['printTestSpec'] = "Print Test Specification"; //printTC.html $TLS_htmltext['printTestSpec'] = "

Purpose:

From here you can print a single test case, all the test cases within a test suite, or all the test cases in a test project or plan.

Get Started:

  1. Select the parts of the test cases you want to display, and then click on a test case, test suite, or the test project. A printable page will be displayed.

  2. Use the \"Show As\" drop-box in the navigation pane to specify whether you want the information displayed as HTML or in a Microsoft Word document. See help for more information.

  3. Use your browser's print functionality to actually print the information.
    Note: Make sure to only print the right-hand frame.

"; // ------------------------------------------------------------------------------------------ $TLS_htmltext_title['reqSpecMgmt'] = "Requirements Specification Design"; //printTC.html $TLS_htmltext['reqSpecMgmt'] = "

You can manage Requirement Specification documents.

Requirements Specification

Requirements are grouped by Requirements Specification document, which is related to Test Project.
TestLink doesn't support (yet) 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 to TestLink. 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, if none exists click on the project node to create one. 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_htmltext_title['keywordsAssign'] = "Keyword Assignment"; $TLS_htmltext['keywordsAssign'] = "

Purpose:

The Keyword Assignment page is the place where users can batch assign keywords to the existing Test Suite or Test Case

To Assign Keywords:

  1. Select a Test Suite, or Test Case on the tree view on the left.
  2. The top most box that shows up on the right hand side will allow you to assign available keywords to every single test case.
  3. The selections below allow you to assign cases at a more granular level.

Important Information Regarding Keyword Assignments in Test Plans:

Keyword assignments you make to the specification will only effect test cases in your Test plans if and only if the test plan contains the latest version of the Test case. Otherwise if a test plan contains older versions of a test case, assignments you make now WILL NOT appear in the test plan.

TestLink uses this approach so that older versions of test cases in test plans are not effected by keyword assignments you make to the most recent version of the test case. If you want your test cases in your test plan to be updated, first verify they are up to date using the 'Update Modified Test Cases' functionality BEFORE making keyword assignments.

"; // ------------------------------------------------------------------------------------------ $TLS_htmltext_title['executeTest'] = "Test Case Execution"; $TLS_htmltext['executeTest'] = "

Purpose:

Allows user to execute Test cases. User can assign Test result to Test Case for Build. See help for more information about filter and settings " . "(click on the question mark icon).

Get started:

  1. User must have defined a Build for the Test Plan.
  2. Select a Build from the drop down box and the \"Apply\" button in the navigation pane.
  3. Click on a test case in the tree menu.
  4. Fill out the test case result and any applicable notes or bugs.
  5. Save results.

Note: TestLink must be configurated to collaborate with your Bug tracker if you would like to create/trace a problem report directly from the GUI.

"; // ------------------------------------------------------------------------------------------ $TLS_htmltext_title['showMetrics'] = "Description of Test Reports and Metrics"; $TLS_htmltext['showMetrics'] = "

Reports are related to a Test Plan " . "(defined in top of navigator). This Test Plan could differs from the current Test Plan for execution. You can also select Report format:

  • Normal - report is displayed in web page
  • MS Excel - report exported to Microsoft Excel
  • HTML Email - report is emailed to user's email address
  • Charts - report include graphs (flash technology)

The print button activate print of a report only (without navigation).

There are several seperate reports to choose from, their purpose and function are explained below.

General Test Plan Metrics

This page shows you only the most current status of a Test plan by test suite, owner, and keyword. The most 'current status' is determined by the most recent build test cases were executed on. For instance, if a test case was executed over multiple builds, only the latest result is taken into account.

'Last Test Result' is a concept used in many reports, and is determined as follows:

  • The order in which builds are added to a Test Plan determines which build is most recent. The results from the most recent build will take precendence over older builds. For example, if you mark a test as 'fail' in build 1, and mark it as 'pass' in build 2, it's latest result will be 'pass'.
  • If a test case is executed mulitple times on the same build, the most recent execution will take precedence. For example, if build 3 is released to your team and tester 1 marks it as 'pass' at 2PM, and tester 2 marks it as 'fail' at 3PM - it will appear as 'fail'.
  • Test cases listed as 'not run' against a build are not taken into account. For example, if you mark a case as 'pass' in build 1, and don't execute it in build 2, it's last result will be considered as 'pass'.

The following tables are displayed:

  • Results by top level Test Suites Lists the results of each top level suite. Total cases, passed, failed, blocked, not run, and percent completed are listed. A 'completed' test case is one that has been marked pass, fail, or block. Results for top level suites include all children suites.
  • Results By Keyword Lists all keywords that are assigned to cases in the current test plan, and the results associated with them.
  • Results by owner Lists each owner that has test cases assigned to them in the current test plan. Test cases which are not assigned are tallied under the 'unassigned' heading.

The Overall Build Status

Lists the execution results for every build. For each build, the total test cases, total pass, % pass, total fail, % fail, blocked, % blocked, not run, %not run. If a test case has been executed twice on the same build, the most recent execution will be taken into account.

Query Metrics

This report consists of a query form page, and a query results page which contains the queried data. Query Form Page presents with a query page with 4 controls. Each control is set to a default which maximizes the number of test cases and builds the query should be performed against. Altering the controls allows the user to filter the results and generate specific reports for specific owner, keyword, suite, and build combinations.

  • keyword 0->1 keywords can be selected. By default - no keyword is selected. If a keyword is not selected, then all test cases will be considered regardless of keyword assignments. Keywords are assigned in the test specification or Keyword Management pages. Keywords assigned to test cases span all test plans, and span across all versions of a test case. If you are interested in the results for a specific keyword you would alter this control.
  • owner 0->1 owners can be selected. By default - no owner is selected. If an owner is not selected, then all test cases will be considered regardless of owner assignment. Currently there is no functionality to search for 'unassigned' test cases. Ownership is assigned through the 'Assign Test Case execution' page, and is done on a per test plan basis. If you are interested in the work done by a specific tester you would alter this control.
  • top level suite 0->n top level suites can be selected. By default - all suites are selected. Only suites that are selected will be queried for result metrics. If you are only intested in the results for a specific suite you would alter this control.
  • Builds 1->n builds can be selected. By default - all builds are selected. Only executions performed on builds you select will be taken into account when producing metrics. For example - if you wanted to see how many test cases were executed on the last 3 builds - you would alter this control. Keyword, owner, and top level suite selections will dictate the number of test cases from your test plan are used to computate per suite and per test plan metrics. For example, if you select owner = 'Greg', Keyword='Priority 1', and all available test suites - only Priority 1 test cases assigned to Greg will be considered. The '# of Test Cases' totals you will see on the report will be influenced by these 3 controls. Build selections will influence if a case is considered 'pass', 'fail', 'blocked', or 'not run'. Please refer to 'Last Test Result' rules as they appear above.

Press the 'submit' button to proceed with the query and display the output page.

Query Report Page will display:

  1. the query parameters used to create report
  2. totals for the entire test plan
  3. a per suite breakdown of totals (sum / pass / fail / blocked / not run) and all executions performed on that suite. If a test case has been executed more than once on multiple builds - all executions will be displayed that were recorded against the selected builds. However, the summary for that suite will only include the 'Last Test Result' for the selected builds.

Blocked, Failed, and Not Run Test Case Reports

These reports show all of the currently blocked, failing, or not run test cases. 'Last test Result' logic (which is described above under General Test Plan Metrics) is again employed to determine if a test case should be considered blocked, failed, or not run. Blocked and failed test case reports will display the associated bugs if the user is using an integrated bug tracking system.

Test Report

View status of every test case on every build. The most recent execution result will be used if a test case was executed multiple times on the same build. It is recommended to export this report to Excel format for easier browsing if a large data set is being used.

Charts - General Test Plan Metrics

'Last test Result' logic is used for all four charts that you will see. The graphs are animated to help the user visualize the metrics from the current test plan. The four charts provide are :

  • Pie chart of overall pass / fail / blocked / and not run test cases
  • Bar chart of Results by Keyword
  • Bar chart of Results By Owner
  • Bar chart of Results By Top Level Suite

The bars in the bar charts are colored such that the user can identify the approximate number of pass, fail, blocked, and not run cases.

This report page requires your browser have a flash plugin (by http://www.maani.us) to display results in a graphical format.

Total Bugs For Each Test Case

This report shows each test case with all of the bugs filed against it for the entire project. This report is only available if a Bug Tracking System is connected.

"; // ------------------------------------------------------------------------------------------ $TLS_htmltext_title['planAddTC'] = "Add / Remove Test cases to Test Plan"; // testSetAdd $TLS_htmltext['planAddTC'] = "

Purpose:

Allows user (with lead level permissions) to add or remove test cases into a Test plan.

To add or remove Test cases:

  1. Click on a test suite to see all of its test suites and all of its test cases.
  2. When you are done click the 'Add / Remove Test Cases' button to add or remove the test cases. Note: Is not possible to add the same test case multiple times.
"; // ------------------------------------------------------------------------------------------ $TLS_htmltext_title['tc_exec_assignment'] = "Assign Testers to test execution"; $TLS_htmltext['tc_exec_assignment'] = "

Purpose

This page allows test leaders to assign users to particular tests within the Test Plan.

Get Started

  1. Choose a Test case or Test Suite to test.
  2. Select a planned tester.
  3. Press button to submit assignement.
  4. Open execution page to verify assignment. You can set-up a filter for users.
"; // ------------------------------------------------------------------------------------------ $TLS_htmltext_title['planUpdateTC'] = "Update Test Cases in the Test Plan"; $TLS_htmltext['planUpdateTC'] = "

Purpose

This page allows update Test case to a newer (different) version in the case that Test Specification is changed. It often happens that some functionality is clarified during testing." . " User modifies Test Specification, but changes needs to propagate to Test Plan too. Otherwise Test" . " plan holds original version to be sure, that results refer to the correct text of a Test case.

Get Started

  1. Choose a Test case or Test Suite to test.
  2. Choose a new version from bombo boxmenu for particular Test case.
  3. Press button 'Update Test plan' to submit changes.
  4. To verify: Open execution page to view text of the test case(s).
"; // ------------------------------------------------------------------------------------------ $TLS_htmltext_title['test_urgency'] = "Specify tests with high or low urgency"; $TLS_htmltext['test_urgency'] = "

Purpose

TestLink allows set urgency of Test Suite to affect a testing Priority of test cases. Test priority depends on both Importance of Test cases and Urgency defined in the Test Plan. Test leader should specify a set of test cases that could be tested at first. It helps to assure that testing will cover the most important tests also under time pressure.

Get Started

  1. Choose a Test Suite to set urgency of a product/component feature in navigator on the left side of window.
  2. Choose a urgency level (high, medium or low). Medium is default. You can decrease priority for untouched parts of product and increase for components with significant changes.
  3. Press the button 'Save' to submit changes.

For example, a Test case with a High importance in a Test suite with Low urgency " . "will be Medium priority."; // ------------------------------------------------------------------------------------------ ?>