Improve Re-use of Test Assets by Product Line Engineering
Meta-Information
Origin: Tobias Sorg, Ralf Bogusch, Roland Scherer, / all Airbus Defence And Space.
Written: September 2014
Purpose: Reduce effort and improve quality for test model variants by identifying commonalities and variabilities within a product family engineering. The main idea is to exploit a given product variability model to support a type of impact analysis that maps a failed test case to the test product family test model specifications, which then identifies the commonalities that need to be corrected in the test model (and/or products).
Context/Pre-Conditions: Failed test case, identified commonalities and variabilities.
To consider: knowledge about the involved product line and its variation points.
Used Terms:
Product family: a group of products developed to exploit their commonalities and defined variabilities.
Commonalities: Items that are identical in all products.
Variabilities: Items that are different in the products.
Product configuration: allocates items to products.
.
Structure
Create Product Family Test and Variability Models:
Participants (and Important Artefacts)
Product Manager: Responsible for defining the scope of the product family.
Product Developer: Responsible for the definition of a variability model for the product family and engineers specific product variants within this product family.
Test Engineer: Responsible for developing a requirements-based product family test model.
.
Actions / Collaborations
(1) Based on a given set of input requirements a product family test model is developed by the test engineer, where this model is covering all functionality for the product family. In parallel the product developer is analysing all commonalities, variabilities and dependencies between features and equipments as this items have been identified from the product manager through the scoping process.Outcome of this analysis is a variability model for the whole product fa.
(2) Developing the product family configuration is done by linking identified features to the input requirements and by mapping the features to specific product variants.
(3) Once the product family configuration is developed, it is used to automatically generate product variant test models. This is done by applying the configuration on the overall product family test model.
(4) For the product test model test cases can be generated and executed automatically.
(5) Once a test case result is „failed“, caused by an erroneous test model, the impact of this failed test case on the product family test model and the other product test models will be determined. Since the requirements are referred to in the test cases and the requirements are linked to transitions in the product models, this can be easily done. Following the trace information the error source can be determined in the product family test model. As soon as this error is corrected (step 1), by applying the product configuration implicitely corrected versions of the product variant test models are re-generated (step 3).
.
Discussion
Benefits:
– Reducing costs for development of test models for product variants: Once product family engineering has identified all commonalities and variabilities, it is sufficient to develop one overall test model for the whole product family, where all product variant specific test models can be automatically generated from.
– Avoiding costs for detecting identical errors in test model variants: A test execution with a fail-verdict for one product variant, caused by an incorrect part of a product family test model (where this part has been identified as common for all product variants), will lead to less errors in test runs for the other product variants, when the test model has been corrected.
Comments:
– Another possibility is that not the model, but the SUT has errors. The approach is quite similar to the one described before. Through tracing from test cases to requirements and from requirements to executable code an error identified in a product variant testing campaign and corrected in a commonly used source code module needs not to be fixed again for other product variants.
.
Application Examples
MBAT Aerospace Use Case 5 (Degraded Vision Landing Aid System) / Scenario 07 (Enhance existing Test Model for Product Family Approach):
Participants / Artefacts:
Product Manager: defines the scope of the product family via a feature matrix in MS Excel.
Product Developer: develops a variability model and engineers specific product variants with All4Tec MaTeLo
Test Engineer: develops a requirements-based product family test model with All4Tec MaTeLo.
.
Relations to other Patterns
| Pattern Name | Relation |
| MBT | MBT helps in detailing activity 4 |