Test Case Build & Environment Context in AXQA

Build & Environment Context in Test Cases

AXQA connects Test Case execution to the Build and Environment being validated so results remain traceable to the correct software version.
A Test Case can use a specific Build, while AXQA can also fall back to the Current Project Build when no Test Case-specific Build is assigned.

Why it matters

Connects QA results to the software version that was actually tested.
Prevents results from different releases from being mixed together.
Preserves Build and Environment context in execution history.

When to use it

When a project contains multiple Builds.
When testing the same Test Case across multiple releases.
When execution results must identify the tested Environment.
When preparing release evidence.

Core concepts

Project Build – A Build configured inside the Current Project.
Test Case Build – A specific Build assigned to a Test Case.
Current Build – The active Project Build used as the default context.
Environment – The Environment associated with the selected Build.
B/V/P – Build, Version, and Platform information displayed in the Test Case Manager.
Execution Snapshot – Build context stored with a Test Case execution.

How it works

A project contains one or more Builds.
A Test Case may reference a specific Build.
If no Test Case-specific Build is assigned, AXQA can use the Current or active Project Build as the effective Build.
Environment information is derived from the effective Build.
Execution stores Build-related information with the run history.

How to use it

Step 1: Configure Project Builds

Create the required Builds from the Project Build Management area.

A Build can contain information such as:

Build Number
Version
Environment
Platform

Step 2: Review B/V/P in Test Case Manager

The B/V/P column displays the Build / Version / Platform context used by the Test Case.

The Environment is displayed separately.

Step 3: Assign a specific Build

When a Test Case must remain associated with a specific release, select that Build from the Test Case Manager.

This creates a Test Case-specific Build reference.

Step 4: Use the Current Build as default

If the Test Case does not have its own Build assigned, AXQA can use the project's Current or active Build as the effective context.

This allows a project to move to a newer Build without manually assigning every Test Case.

Step 5: Select a Build for an execution when available

Supported execution flows may allow a Build to be selected when starting a Test Case run.

The selected execution context is then stored with the execution record.

Step 6: Review historical Build information

Test Case execution records preserve information including:

Build
Version
Platform
Environment

This keeps historical results associated with the context used at execution time.

Best practices

Keep the Current Project Build updated.
Assign a Test Case-specific Build only when the Test Case needs to remain tied to that release.
Confirm Environment before running release-sensitive tests.
Do not interpret Environment independently from its Build context.
Use execution history when comparing results across Builds.

Common mistakes

❌ Assuming every Test Case must have its own Build manually assigned.
✔ Test Cases without a specific Build can use the Current Project Build as their effective context.

❌ Treating Environment as a separate Test Case field.
✔ Environment is derived from the effective Build.

❌ Changing the Current Build and assuming historical execution data is rewritten.
✔ Historical execution records preserve the Build context captured during the run.

Security & permissions

Build selections are validated against the Current Project.
A Test Case cannot use a Build belonging to another project through supported Test Case operations.
Execution history stores Build context for traceability.
Build changes performed through supported Test Case editing are included in Audit History.

AXQA

Did You Know?