Tests

​

Description

Tests capture verification and validation activities that provide evidence a system meets its requirements. A Test can represent a physical or software test, analysis, inspection, demonstration, or milestone review, based on its project-defined category. Tests complement Requirements: requirements describe what the system must satisfy, while tests define the activity and evidence used to verify it. Link a Test to the requirement it verifies using a verify relationship.

​

Test Hierarchy

Tests can contain child Tests. A leaf Test records its own result and verdict. A parent Test rolls up the verdicts of its children according to the category’s configured rollup mode. Parent rollups use the numeric scores assigned to each category verdict. The selected category determines how those child scores become the parent’s verdict.

​

Evaluation

A leaf Test evaluates one observed result against its evaluation criteria:

1. Define the expected observation type in Results Value: number, text, or boolean.
2. Provide the observed value directly or calculate it with an equation or reference.
3. Map result ranges or values to named verdicts in Evaluation Criteria.
4. The Test resolves to the matching category verdict.

When criteria overlap, cannot be resolved, use an incompatible result type, or refer to an unavailable category verdict, the Test displays a configuration error rather than a valid verdict.

​

State-specific Results and Thresholds

Use [attribute-uuid].state([state-uuid]) in Results Value or a numeric criterion when the Test must use an Attribute’s effective value for one named State. State equations resolve first, followed by trigger-path rollup, parent-state inheritance, and default-value fallback. This explicit state is independent of any ambient state in which another equation is evaluated. The receiver must be an Attribute and the argument must be a State. This is a value accessor, not an executable method; only [code-uuid].method(args) with a Code receiver executes code. If a state value is an array, select a 1-based index or use min(), max(), or mean() to produce the single scalar required by evaluation criteria.

​

Evaluation Criteria Target Syntax

Numeric targets use an optional comparator (>=, <=, >, <, =, or !=) followed by a number or resolvable numeric expression. A bare number is an exact match. Use to for one continuous range:

• -20 to 60 includes both boundaries.
• > -20 to < 60 excludes both boundaries.
• < [minimum-uuid] or > [maximum-uuid] uses referenced numeric bounds.

Use whitespace-delimited or to join numeric clauses when a verdict accepts disjoint regions. A value matches if it matches any clause:

• Pass: -20 to 60
• Fail: < -20 or > 60

In this partition, -20 and 60 match Pass; only values below -20 or above 60 match Fail. to is not interchangeable with or: to defines one interval while or joins separate clauses. Every clause must remain non-overlapping with the target of every other verdict. For example, Pass: -20 to 60 and Fail: < -20 or > 50 is invalid because the second Fail clause overlaps Pass. Each clause must be complete: < -20 or, or > 60, and < -20 or > 60 are malformed. OR unions are supported only for numeric targets; String targets are exact text and Boolean targets are true or false.

​

Status

Status tracks the Test activity lifecycle. Leaf Tests set status directly; parent Tests roll up status from their children. Running a Test executes its configured procedure when applicable, records the resulting evidence, and can advance status (for example from pending to started or done). Cancelled and waived Tests are blocked from running. Equation-based results can also update a verdict as referenced model values change.

​

Categories and Verdicts

Each Test uses a category configured in the project’s Test Categories settings. A category defines the available verdict names, colors, normalized scores, and parent rollup mode. New projects include categories for Test, Analysis, Inspection, Demonstration, and Milestone Review. The first four typically use Pass and Fail verdicts; Milestone Review includes readiness verdicts such as Go, Conditional Go, and No-Go. Projects can customize these categories and verdicts to match their verification process.

​

Rollup Modes

New projects use Weighted for Test, Analysis, Inspection, and Demonstration categories. Milestone Review uses Minimum so the least-ready review area controls the overall outcome.

​

View Types

​

Properties Fields