Projects often include tests in their systems engineering (SE) model to ensure that the quality and compliance of the realized objects meet the specified requirements. While verifications are mainly used during the design phase of a project, the terms test and inspection are mainly used during the implementation phase and the operational phase of the project. As in SE, the terms test and inspection are often used interchangeably, the term test will be used hereafter for clarity and simplicity.
Based on observations at projects, the basic model consists of a type element named Test, which includes type properties to store the Name, Description, Date, Location, Result, and Explanation of result.
Typically, the type property Name has the data type of Single line text (to provide a brief title for recognizing the test), and the type property Description has the data type of Single line text (to provide a more detailed description of the test). The type property Date has the data type of Date (to track when the test was performed), and the type property Location has the data type of Single line text (to provide the physical area where the test was performed). Finally, the type property Result has the data type of Text (to describe the outcome of the test in full detail), and the type property Explanation of result has the data type of Text (to provide an additional rationale for the explanation of the test).
In terms of relations, it is common to have a type relation, has responsible, between the type elements Test and Person. In most projects, the cardinality of this relation is set to Single. This prevents people from not feeling responsible when multiple persons are related. Finally, in the model, a type relation has proof is included between the type elements Test and Document. Once a test has been performed, the tester uses this relation to pinpoint the test to a document that contains the proof of the outcome of the test. In most projects, the cardinality of this relation is set to Multi as multiple documents can address the test results.
Subject
In projects where tests are part of the designed SE model, we often see that the subjects of these tests are also captured in the SE model. The most frequent subjects of tests are objects and activities. A test is not limited to having only one subject. It can be that multiple subjects are to be inspected in a single test. Therefore, a Multi relation from the Test to the Object is included in this example. This same construction applies to a model where activities are the subject of a test as well.
Lifecycle
When tracking a test’s progress over time is necessary, it is often decided to add a Status property to the model with the data type List. Examples of list values include Open, Compliant, Non-compliant, Rejected, and others. This helps users filter relevant tests.
When it is anticipated that some tests may become irrelevant to the project over time, it is beneficial to configure the Status type property as a Lifecycle property for the Test type element. This can be done by setting the Lifecycle property of the Test type element to the Status type property.
Additionally, by enabling the Auto archive setting and selecting the relevant archive values (e.g., Rejected), only relevant tests will be displayed by default in the views.
Scope
A test often inspects whether or not the requirements related to the subjects are met. A relation between Test and the type element Requirement is needed to indicate what requirements need to be inspected.
Earlier, we mentioned that an Object can be selected as a subject for a Test. The model shows that Object is also related to Requirement. When configuring the relation between Test and Requirement, the circular dependency functionality can help users select only the requirements for the tested object. This same construction can also be applied when the subject of a Test is an Activity, but only if the Activity type element is also related to Requirements.