...
The descriptive name should briefly, in three to six words, express what system is tested, which the target aspects, feature features of components are, what kind of testing is conducted or for which purpose, and level, type or purpose of conducted testing.
It should be immediately followed by separate description of the testing level (unit, integration, system, acceptance) and/or type or subtype (functional, non-functional, alpha, beta, performance, load, stress, usability, security, conformance, compatibility, resilience, scalability, volume, regression…).
...
The purpose of the section is to describe list individual features and their significance or risk from the user perspective. It is a listing of what is to be tested from the users’ viewpoint in terms of what the system does. The individual features may be operations, scenarios, and functionalities that are to be tested across all or within individual tested sub-systems. Features may be rated according to their importance or risk.
...
Test design specification addresses the test objectives by refininig refining the features to be tested, testing approach, test cases, expected results procedures and test pass criteria. This document also establishes groups of related test items togethercases.
Features to be Tested
This section identifies the test items and describes the features or requirements and combinations of features that the subject of testing .
Level of testing appropriate to test item if the test design specification covers more than one level of testing.
Reference 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 this test objective (feature) was obtained.
Attributes and Characteristics
Groupings of Features
The features may be grouped around the few key applications or use cases.
the feature is detailed. These 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.
The features may be grouped into a few key applications, use cases or scenarios. If such groping is made, a single feature or requirement may be present in several groups.
The use case is a high level description of a specific system usage, or set of system behaviours or functionalities. It should not be mistaken for UML use case. It implies, from the end-user perspective, a set of tests The Use Case is a high level description of a specific system usage, or set of system behaviours or functionalities. It should not be mistaken for UML use case. It implies, from the end-user perspective, a set of tests that need to be conducted in order to consider the system as operational for particular type of use. It therefore usually describes the system usage, features and related requirements and that are necessary for utilization of the system by end users on regular basis.For each feature or feature combination, a reference to its associated requirements in the item requirement specification or design description should be included.
On the base of identified features, the requirements are defined.
The requirement is a description of necessary capability, feature, functionality, characteristic or constraint Requirement is a high level description of necessary capability, feature, functionality, characteristic or constraint that the system must meet or be able to perform. It is a statement that identifies a necessary quality of a system for it to have value and utility to a user, customer, organization, or other stakeholder. It is necessary for the fulfillment of one or several use cases or usage scenarios (in scenario testing).or several use cases or usage scenarios (in scenario testing).
The higher level of requirements include business, architectural and stakeholder/user requirements. There are also some transitional requirements that are only relevant during the implementation of the system. On the base of identified high-level features or requirements, the detailed requirements are defined.The
Functional requirement defines a specific behavior or function (what the system does; not how - in terms of implementation, quality, or performance).
Non-functional requirement specifies the quality criteria used to assess the characteristics or properties the system should possess (what it is). Typical non-functional requirements include:
- Performance, availability, stability, load capacity, efficiency, effectiveness, scalability, response time
- Reliability, robustness, fault tolerance, resilience, recoverability
- Privacy, security, safety
- Configuratability, supportability, operability, maintainability, modifiability, extensibility
- Testability, compliance, certification
- Usability, accessibility, localization, internationalization, documentation
- Compatibility, deployability, interoperability, portability, reusability
The requirements specification is an explicit set of requirements to be satisfied by the system, and is therefore usually produced quite early in its development. Such a specification may be a direct input for testing process, as it lays out all requirements that were, hopefully, addressed during the system development. Alternatively, the requirements that are directly associated with testing can be formulated, without the prior input of access to the requirements produced during development.
Functional
Non-functional
The individual requirement need to be mutually consistent, consistent with the external documentation, verifiable, and traceable towards high-level requirements or stakeholder needs, but also towards the test cases.
The requirements are the base for development of test cases.
Scenario testing Scenario Testing is a higher level approach to testing of complex systems that is not based on Test Casestest cases, but on working through realistic and complex stories reflecting user activities. These stories may consist of one or several user stories,which capture what a user does or needs to do as part of his or her job function, expressed through one or more sentences in the everyday or domain language. The tester who follows the scenario must interpret the results and evaluate whether they can be considered as a pass or failure. This interpretation may require backing by domain experts. This term should be distinguished from Test Procedure and Test Case scenario.
The requirements are the base for elaboration of the test cases.
Approach Refinements
Specify refinements to the approach described in the test plan. Include specific test techniques to be used.The method of analyzing test results should be identified (e.g., comparator programs or visual inspection).
Also deviations from the plan
Test Cases
Identify test cases.
Some test cases may be related to several use cases.
List the identifier and a brief description of each test case associated with this design. A particular test case may be identified in more than one test design specification. List the identifier and a brief description of each procedure associated with this test design specification.
Specify the results of any analysis that provides a rationale for test case selection. For example, one might specify conditions that permit a determination of error tolerance (e.g., those conditions that distinguish valid inputs from invalid inputs).
Summarize the common attributes of any test cases. This may include input constraints that must be true for every input in the set of associated test cases, any shared environmental needs, any shared special procedural requirements, and any shared case dependencies.
test procedure and test case scenario.
Approach Refinements
This section refines the approach described in the test plan. Specific test techniques to be used are selected and justified.The method for the inspection and analysis of test results is identified (for example, visual inspection of behaviours and outputs, use of instruments or comparator or pattern matching programs, or test automation tools that can capture and process outputs).
Provided are details of the included test levels and how the individual features are addressed at those levels.
In order to avoid redundancy, common information is related to several test cases or procedures is provided here. It may include details of the test environment or environmental needs, system setup and recovery or reset, and dependencies between the test cases.
If the test design includes some deviations from the test plan, they are described here.
Test Cases
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 attributes may also be recorded.
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 cases may be the result of an analysis that provides a rationale for a particular battery of test cases. 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 Traceability Matrix, which is usually placed in a separate document that is updated with the evolution of the requirements and test design specification, but also refinement of individual test casesRepresentation of test case traceability is modeled through the Test Matrix.
Feature Pass/Fail Criteria
Specify This specifies the criteria to be used to determine whether the feature or feature combination 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 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.
...