Tests

Plan, run, and track verification — test cases, plans, runs, CI evidence ingest, and milestones with connected defects.

The test capabilities support verification and validation: define test cases that prove requirements are met, organize them into plans, run them, and capture evidence as you go. Verification stays linked to the requirements it proves, so coverage and suspect status are always live.

This section covers the full testing workflow, from authoring a test case to running a plan, ingesting CI evidence, then tracking milestones, defects, and coverage.

Verification that stays connected to what it proves

The value of a test in a regulated program isn’t just its result — it’s the link between that result and the requirement it verifies. traceunified keeps that link live. A test case references the requirements it proves, so coverage (is every requirement verified) and suspect status (has something changed that invalidates a past result) are always current rather than reconstructed before an audit. Verification isn’t a separate silo; it’s part of the same connected record as the specification it checks.

From test case to run to evidence

The workflow moves in clear stages. Test cases with steps define exactly what gets verified and how. Test plans organize those cases into a coherent run for a milestone or a release. Runs execute the plan and capture results — pass, fail, and the evidence behind each — as you go. CI can also submit results over the API or as JUnit with PEM or keyless Sigstore attestation — see CI evidence ingest. Those land as automated evidence; a person promotes them to a signed Passed/Failed. Milestones and schedules let you plan verification over time rather than treating it as a last-minute scramble, and defects logged against failures link back to the items they affect so nothing falls through.

Coverage as a first-class signal

Because tests trace to requirements, coverage becomes something you can measure and prove rather than assert. The coverage view shows which requirements are verified, which aren’t, and where a change has left a gap — turning “is everything tested” from a hopeful yes into a defensible one.

What’s in this section

Was this helpful?