Test Build Management & Version Tracking in AXQA

Builds allow you to connect your testing work to a specific version of the product. Instead of running tests in isolation, you can clearly track which release, patch, or iteration each execution belongs to.

Why it matters

• Provides clear traceability between executions and product versions.
• Makes regression analysis easier across multiple releases.
• Improves reporting accuracy when reviewing Test Campaign results.

When to use it

• You are testing a new release, patch, or hotfix.
• You want to compare results between two versions.
• You need structured release tracking for clients or stakeholders.
• You’re running recurring regression Test Campaigns for each build.

Core concepts

• Build – A specific version or release of the product being tested.
• Current Build – The active build associated with new executions.
• Version Label – Human-readable identifier (e.g., 1.4.2, 2026.02, Patch-12).
• Platform (optional) – Environment or device type if relevant (e.g., Web, Mobile, Console).

How it works

1. When creating or editing a project, you can define an initial build.
2. Each build is stored as a separate entry tied to the project.
3. One build is marked as the current active build.
4. New test executions and Test Campaign runs are associated with the current build.
5. Historical builds remain available for filtering and reporting.

How to use it

Step 1: Add a new build

When a new version is ready for testing, create a new build entry and define its version label. Optionally specify platform or environment if relevant.

Step 2: Set it as current

Mark the new build as the active one. From that point forward, executions will be linked to this version.

Step 3: Run Test Campaigns

Execute your test cases or Test Campaigns under the active build. Reports will reflect which version the results belong to.

Step 4: Keep history intact

Avoid modifying older builds. Instead, create new entries to maintain a clean release history.

Best practices

• Create a new build for every meaningful release or patch.
• Use consistent naming conventions for version labels.
• Do not overwrite historical build data.
• Align build updates with release management processes.

Common mistakes

❌ Editing an old build instead of creating a new one
✔ Create a new build entry to preserve accurate history.

❌ Forgetting to switch the active build before execution
✔ Confirm the correct build is marked as current before running Test Campaigns.

❌ Using inconsistent version naming
✔ Adopt a structured format (e.g., Major.Minor.Patch).

Security & permissions

• Only authorized users can create or modify builds.
• Build history remains protected and cannot be altered accidentally.
• Changing the current build affects future executions only.

Related documentation

• Managing Project Settings
• Project Status & Lifecycle
• Test Campaign Overview