Test Management as Code (TMaC)

Operational Truth

Quality You Can Prove. Where quality intent and operational reality are always comparable, traceable, and provable.

Test Artifacts as Requirements Documents for Quality

Design Time: Expected Tests

In software development, a requirements document defines what the system is supposed to do. It describes intent, not what actually happens during execution.

In Qualityfolio, test artifacts written as code play the same role—they define what quality, compliance, security, and behavior are expected of a system.

Runtime: Observed Results

Observed Results represent runtime reality—what we can actually see when tests are executed and evidence is collected.

  • • Test execution results and evidence files
  • • Security scan outputs and CI/CD outcomes
  • • Runtime checks and verification records

A test artifact says: "This behavior must be verified."
Execution either produces valid evidence—or it does not.

The Qualityfolio Artifact Hierarchy

A single, structured file that captures quality intent in a strict, machine-readable hierarchy.

Project

The system or product under test

Strategy

The testing and assurance approach

Plan

Scope, objectives, and coverage intent

Suite

Logical grouping of related tests

Test Case

Specific, verifiable expectation

Evidence

Proof produced when test is executed

This hierarchy is explicit, inspectable, and machine-readable.

How Qualityfolio Encodes Operational Truth

Nothing is implicit. Nothing is external. All intent, execution, and proof live in the artifact.

Test cases define what must be verified

They are the source of Expected Tests—declarations of quality intent.

Evidence blocks define what actually happened

Execution details, results, and artifacts are captured as structured evidence.

Test cycles are structured fields

Recorded inside YAML blocks at the evidence level, preserving historical execution truth without duplicating tests.

Requirements are attached by override

Introduced by overriding the plan or suite, allowing a single requirement to govern multiple test cases.

Issues are attached at the point of failure

Declared at the evidence level, directly tied to the observed outcome that triggered them.

Operational Truth is not reconstructed after the fact. It is encoded directly into the test artifacts themselves.

Detecting Truth Gaps

Operational Truth emerges only when every test case has evidence and every piece of evidence maps back to a test case.

Test Case Without Evidence

If a test case exists but no corresponding evidence block exists, the system's quality intent was defined but never proven.

Execution Failure

Pipelines did not run or environments were unavailable

Process Failure

Test was skipped, forgotten, or manually bypassed

Compliance Failure

Required control declared but never validated

Qualityfolio treats this as an unverified expectation—not a passed test.

Evidence Without Test Case

If evidence exists without a corresponding test case, it means execution occurred without declared intent—a governance failure.

Behavior Never Defined

The test case was never formally declared

Cannot Be Traced

Cannot be mapped to requirements or plans

Not Defensible

Creates false confidence or audit noise

If execution is not declared as a test case, it is not trusted as proof.

When Expected and Observed Align

Tests + Evidence Align

Quality is provable and auditable

Tests Lack Evidence

Assurance is incomplete

Evidence Without Tests

Governance is broken

Operational Truth Is the Foundation of Qualityfolio

Just as modern engineering rejects undocumented code in production, Qualityfolio rejects:

Test cases without evidence Evidence without test cases Claims without proof

Operational Truth is not a report. It is a continuously validated state.

Ready to Encode Your Operational Truth?

See how Qualityfolio's Test Management as Code ensures quality intent and operational reality are always aligned.