Test Case Audit History

Test Case Audit History records important changes made to a Test Case and its Test Steps.
It provides a traceable view of what changed, the previous and new values, who made the change, and when the change occurred.

Why it matters

• Improves accountability for Test Case changes.
• Helps teams investigate unexpected configuration changes.
• Provides traceability for QA governance and operational reviews.

When to use it

• When investigating why a Test Case changed.
• When reviewing modifications before a release.
• When checking who changed assignment, priority, build, or execution settings.
• When reviewing Step changes or status changes.

Core concepts

• Audit Entry – One recorded Test Case change.
• Field – The Test Case or Step property that changed.
• Old Value – The value before the change.
• New Value – The value after the change.
• Changed By – The user responsible for the change.
• Changed At – The time the change was recorded.

How it works

1. AXQA detects supported Test Case or Step changes.
2. The previous and new values are captured.
3. The user performing the change is recorded.
4. The timestamp is stored.
5. Audit History can later be opened from the Test Case Manager.

How to use it

Step 1: Open Audit History

Locate the Test Case in the Test Case Manager.

Open its Audit History action.

Step 2: Review the summary

AXQA provides information such as:

• Number of audit entries
• Number of changed fields
• Most recent change
• User responsible for the most recent change

Step 3: Review individual changes

Each audit entry can show:

• Field
• Previous value
• New value
• Changed By
• Changed At

Step 4: Review Step changes

Audit History can also record supported changes to Test Steps, including:

• Step creation
• Step updates
• Step deletion
• Step Status changes

Step 5: Review table changes

Supported Inline Editing and Bulk Changes also create Test Case audit entries.

This allows operational updates performed directly from the Test Case Manager to remain traceable.

Best practices

• Review Audit History when investigating unexpected Test Case behavior.
• Use meaningful Category, Priority, Group, and Build values so changes remain understandable.
• Avoid unnecessary repetitive updates that create noisy audit history.
• Combine Audit History with Execution History when investigating a testing incident.

Common mistakes

❌ Looking only at the current Test Case configuration when debugging a change.
✔ Check Audit History to understand what changed over time.

❌ Confusing Audit History with Execution History.
✔ Audit History tracks configuration changes; Execution History tracks testing activity and results.

Security & permissions

• Audit History is associated with the Test Case and its project.
• Change records identify the user responsible for supported modifications.
• Audit data does not replace normal project-access controls.
• Audit History should be treated as operational traceability data.

Related documentation

• Test Case Manager Overview
• Inline Editing & Bulk Test Case Changes
• Test Case Progress & Custom Step Statuses
• Execution History