Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This section describes the features or requirements and combinations of features that the subject of testing and, if some of features are closely related to test items, expresses these associations. Each feature is elaborated through its characteristics and attributes, with references to the original documentation where the feature is detailed. These The requirement descriptors include ID/short name, type, description and risks. The references lead to the associated requirements or feature specifications in the system/item requirement specification or design description (in the original development documentation). If the test design specification covers several levels or types of testing, the associated levels or types are noted for each individual requirement, feature or test item.

...

Individual test cases are identified here. After the identifier, a brief description of the test case and associated test procedure is provided. Associated test levels or other important common test case attributes may also be recorded.

The test case refines criteria that need to be met in order to consider some system feature, set of features or use case as working. It is the smallest unit of testing and is sometimes colloquially referred as Test. A single test case may be included into several test suites or related to a requirement associated with several use cases. If different test levels have separate test design specification, a particular test case may be present in several design specifications.

The selection of the use test cases may be the result of an analysis that provides a rationale for a particular battery of test cases associated with a single requirement. For example, the same feature may be tested with distinct test cases that cover valid and invalid inputs and subsequent successful or negative outcomes. This distinction is made in terms of system responses and not testing outcomes, as reporting of an error may actually indicate passing of a test. The relationship between the requirements/features and test cases is summarised in the logic behind the selection of test cases should be described here.

A feature from the test design specification may be tested in more than one test case, and a test case may test more than one feature. The test cases should cover all features, that is, each feature should be tested at least once. The relationship between the requirements/features and test cases is summarised in the Requirements/Test Cases Traceability Matrix, which is usually placed in a separate document that is updated with the evolution of the requirements and test design specificationSpecification, but also with refinement of individual test cases. It enables both forward and backward traceability, as it simplifies how the test cases need to be modified upon the change of requirements, and vice versa. It is used to verify whether all the requirements have corresponding test cases, and to identify for which requirement(s) a particular test case has been written for. The Requirements/Test Cases Traceability Matrix is a table where requirements and test cases are paired, thus ensuring their mutual association and coverage. Since there are always more test cases than requirements, the requirements are placed in columns, and tests cases in rows. The requirements are identified by their IDs or short names and can be grouped by their types, while the test cases can be grouped into sections according to levels: unit, integration, system, acceptance.

Feature Pass/Feature Pass/Fail Criteria

This specifies the criteria to be used to determine whether the feature or a group of features has passed or failed, on the base of results of individual test cases.

Test Case Specification

The Test Case is a specification of criteria that need to be met in order to consider some system feature, set of features or Use Case as working. It is the smallest unit of testing and is sometimes colloquially referred as Test. It should include a description of the functionality to be tested, and the preparation test case specifications are produced after the test design specification is prepared. The  test case specification is a detailed elaboration of a test case identified in the test design specification and includes a description of the functionality to be tested and the preparation required to ensure that the test can be conducted. A single test case is sometimes associated with several requirements. It may be partially or fully automated.

The test case specification is provided within the use case or test suite specification, a document that details all test cases, or even separate document dedicated to a single test case. A formal written test case is characterised by a known preconditions, input and expected output and postconditions, which are worked out before the execution. The test case may comprise of a single or several steps that are necessary to assess the tested functionality.

For a For a system without preexisting formal requirements, the Test Cases test cases can be written based on system’s desired or usual operation, or operation of similar systems. In this case, they may be a result of decomposition of a high-level scenario, which is a story or setting description used to explain the system and its operation to the tester. Alternatively, Test Cases may be omitted altogether and replaced with scenario testing, which substitutes a sequence or group of Test Cases, as they may be hard to precisely formulate and maintain with the evolution of the system.. Alternatively, test cases may be omitted altogether and replaced with scenario testing, which substitutes a sequence or group of test cases, as they may be hard to precisely formulate and maintain with the evolution of the system.

The typical attributes or segments of the test case specification are:

  • Test case ID or short identifying name
  • Related requirement(s)
  • Requirement type(s)
  • Test level
  • Author
  • Test case description
  • Environment information
  • Test bed(s) to be used (if there are several)
  • Preconditions, prerequisite states or preexisting persistent data
  • Inputs (test data)
  • Execution scenario or test steps
  • Expected postconditions or system states
  • Expected outputs
  • Evaluation parameters
  • Relationship with other use cases
  • Whether the test can be or has been automated
  • Other remarks

The test case typically comprises of several steps that are necessary to assess the tested functionality. The explained  steps should include all necessary actions, including those assumed to be a part of common knowledge.

The test suite is a collection of test cases The Test Suite is a collection of Test Cases that are related to the same testing work in terms of goals and associated testing process. There may be several Test Suites test suites for a particular system, each one grouping together many Test Cases test cases based on corresponding goal and functionality or shared preconditions, system configuration, associated common actions, execution sequence of actions or Test Casestest cases, or reporting requirements. An individual Test Suite test suite may validate whether the system complies with the desired set of behaviors or fulfills the envisioned purpose or associated Use Casesuse cases, or be associated with different phases of system lifecycle, such as identification of regressions, build verification, or validation of individual components. A Test Case test case can be included into several Test Suitestest suites. If Test Cases test cases descriptions are organised along Test Suitestest suites, the overlapping cases should be documented within their primary Test Suites test suites and referenced elsewhere.

A Test Procedure test procedure defines detailed instructions and sequence of steps to be followed while executing a group of Test Cases test cases (such as a Test Suitetest suite) or single Test Casetest case. It can give information on how to create the needed test setup, perform execution and evaluate results for a given test case, evaluate results and restore the environment. The test procedures are developed on the base of the test design specification and in parallel or as parts of test case specifications. Having a formalised test procedure is very helpful when a diverse set of people is involved in performing the same tests at different times and situations, as this supports consistency of test execution and result evaluation. Test Procedure is a combination of Test Cases procedure can combine test cases based on a certain logical reason, like executing an end-to end situation. The , when the order in which the Test Cases test cases are to be run is also fixed.

The Test Script test script is a sequence for instructions that need to be carried out on the tested system in order to execute a test case, or test a part of system functionality. These instructions may be given in the form suitable for manual testing or, in automated testing, as short programs written in a scripting or general purpose programming language. For software systems or applications, there are test tools and frameworks that allow specification and continuous or repeatable execution of prepared automated tests.

...