Share via

Azure DevOps Test Plans – Audit trail capabilities (test changes, deletions, and corrections)

Yair Postolovsky 0 Reputation points
2026-05-20T12:57:38.4+00:00

We are using Azure DevOps Test Plans in a regulated environment where ALCOA data integrity principles apply.

Note: We are looking for an official response from a Microsoft engineer or Azure DevOps product team member, not an AI-generated summary.

Specifically, we need to address the ALCOA requirement:

“Results reflect what occurred, with corrections tracked via audit trail, no overwriting, and appropriate review/approval.”

I would like to understand the official Azure DevOps capabilities related to auditing and traceability of test-related changes:

  1. Audit trail availability

   - Does Azure DevOps provide an audit trail that records changes related to testing artifacts, such as:

     • deletion of test plans, test suites, test cases

     • modification of test cases or test steps

     • changes to test steps during a manual test run

  1. Step-level changes

   - When test steps are edited during test execution (insert, delete, reorder, edit):

     • Is there any audit trail that records who made the change, when it occurred, and what was changed?

     • Is this information available in Test Plans, Test Runs, or elsewhere?

  1. Organization-level Auditing

   - Azure DevOps provides organization-level Auditing (Audit Logs).

     • Does enabling “Log Audit Events” allow tracking of test-related changes (test cases, steps, test runs)?

     • Which audit events or categories should be expected for test modifications or deletions?

     • How can auditing be enabled and accessed for this purpose?

  1. Limitations and best practices

   - If step-level or test-level audit trails are not supported:

     • Can you confirm this as a current product limitation?

     • What level of traceability is officially provided to support compliance requirements such as ALCOA?

The goal is to understand how Azure DevOps Test Plans can support (or where it cannot support) audit trail, non-overwriting, and review/approval requirements for regulated environments.

Thank you.

Azure DevOps

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Pravallika KV 16,030 Reputation points Microsoft External Staff Moderator
    2026-05-20T13:55:10.9166667+00:00

    Hi @Yair Postolovsky ,

    Thanks for reaching out to Microsoft Q&A.

    Here's the rundown on what Azure DevOps Test Plans currently offers for audit-trail and traceability, plus where it’s limited from an ALCOA standpoint:

    1. Artifact-level audit (design time)
      • Test Plans, Test Suites and Test Cases are just work items, so every field change (including editing test steps in the design view) is recorded in the work-item history. You can see who changed what and when right in the UI under the “History” tab.
      • Deleted Test Plans/Suites go into a 14-day soft-delete state and can be restored via the Recycle Bin REST APIs. After 14 days, they’re permanently purged.
      • At the organization level, if you enable Audit Logs (Org settings > Auditing), you’ll get events for create/update/delete on these work-item types.
    2. Step-level changes during a manual run
      • Test run details persist each step’s pass/fail and any “Actual Result” you record.
      • However, if you insert, delete, reorder or edit steps mid-run, those edits overwrite the test-case definition and aren’t separately stamped in history or Audit Logs. There’s no built-in, run-time audit of who made step-by-step edits.
    3. Organization-level auditing
      • Enabling “Log audit events” in Organization Settings captures work-item events (Test Plan, Test Suite, Test Case) under the WorkTracking category.
      • You can view these in the Audit Logs UI or pull them via the REST API. Look for entries like “WorkItemUpdated” or “WorkItemDeleted” that reference your test artifacts.

    Limitations & best practices:

    • There's currently no granular audit for in-run step edits: this is a product limitation.
    • For ALCOA compliance you can combine:
      • Work-item history (design-time changes)
      • Org audit logs (create/update/delete at the artifact level)
      • Retention policies to keep test-run data
      • Process controls (e.g., manual approvals or gated pipelines) to enforce review/sign-off
    • If you need e-signatures or non-overwrite controls on execution data, consider integrating an external compliance tool or adding custom fields + pull-request style approvals around your test assets.

    Was this answer helpful?

  2. AI answer

    2026-05-20T12:58:13.1133333+00:00

    Azure DevOps Test Plans provides traceability and rich test-result history, but the provided context does not describe a full, immutable audit trail at the level required by ALCOA (especially for step-level edits and deletions). The capabilities that are documented can be summarized as follows.

    1. Audit trail availability (test artifacts and execution)

    From the available documentation:

    • Test Plans, test suites, and test cases are standard Azure DevOps work items. They participate in normal work-item linking and traceability, including:
      • Links between requirements, test cases, bugs, and builds.
      • End-to-end traceability views and reports (for example, Requirements Traceability Matrix and Test Analytics).
    • Test execution is captured as test runs and test results, with detailed result records per test case:
      • Each test result includes:
        • Test result summary (execution overview).
        • Linked work items (bugs, requirements, etc.).
        • Test steps with step-by-step outcomes and comments.
        • Attachments (screenshots, logs, etc.).
        • For automated runs, stack trace and analysis information.
      • These results are persisted and can be analyzed later, including failure analysis and attachments.

    However, the context does not document:

    • A dedicated audit log that records creation, modification, or deletion of test plans, suites, or cases.
    • A history log specifically listing who deleted or edited a test case or test step, and when, as a separate audit feature.
    1. Step-level changes during execution

    The documented behavior focuses on execution-time data capture and result analysis, not on an immutable audit trail of step-definition changes:

    • During manual or exploratory testing, Test Runner and the Test & Feedback extension allow:
      • Inline changes to tests during execution.
      • Pause/resume, step pass/fail, bug filing, and rich diagnostic data capture (screenshots, image action log, screen recordings, etc.).
    • Detailed test results show:
      • Test steps and their outcomes.
      • Comments and attachments captured during execution.
      • Analysis information (post-execution analysis and next actions), including customizable dropdowns via the Azure DevOps REST APIs.

    The context does not state that:

    • Edits to test steps (insert, delete, reorder, edit) during execution are recorded in a separate audit log that captures who changed what and when.
    • Such step-definition changes are exposed as a dedicated audit trail in Test Plans, Test Runs, or elsewhere.
    1. Organization-level auditing (Audit Logs)

    The provided context mentions end-to-end traceability and analytics, but does not describe organization-level Audit Logs for test artifacts:

    • Requirements traceability and Test Analytics provide:
      • Association of requirements to test cases, bugs, and code changes.
      • Requirements Traceability Matrix and requirements-quality reports.
      • Views that show bugs and test results together, and source traceability (code changes associated with builds/releases).

    The context does not specify:

    • That enabling organization-level “Log Audit Events” records test-case or step modifications, deletions, or test-run changes.
    • Which audit-event categories, if any, correspond to test modifications or deletions.
    • How to enable and access audit logs specifically for test artifacts.
    1. Limitations and best-available traceability

    Based on the provided material, the officially documented capabilities for test traceability and review/approval are:

    • Requirements traceability:
      • Association of requirements with test cases, bugs, and code changes.
      • Requirements Traceability Matrix and requirements-quality widgets to assess readiness to ship.
    • Test execution traceability:
      • Detailed test results per test case, including step outcomes, comments, attachments, stack traces, and analysis information.
      • Bug traceability: bugs and test results visible together, with linked requirements.
      • Source traceability: ability to see code changes associated with failing tests.
    • Test analytics:
      • Near real-time visibility into test data for builds and releases.
      • Tracking of test plan progress and trends for both manual and automated tests.

    The context does not document:

    • A step-level or test-level immutable audit trail that records all changes (including deletions) with before/after values.
    • An explicit “no overwriting” mechanism or a formal review/approval workflow for test-definition changes that would satisfy ALCOA by design.

    Therefore, within the scope of the provided documentation:

    • Step-level and test-definition audit trails (who changed which step, when, and what the previous value was) are not described and should be treated as a current product limitation for strict ALCOA-style auditing.
    • Azure DevOps Test Plans supports traceability primarily through:
      • Work-item linking (requirements ↔ tests ↔ bugs ↔ code changes).
      • Persistent test runs and detailed test results (including diagnostics and analysis fields).
      • Requirements traceability reports and Test Analytics for monitoring quality and readiness.

    For regulated environments, this means Azure DevOps Test Plans provides strong traceability of execution and linkage between requirements, tests, bugs, and code, but the documentation here does not claim full, immutable audit-trail coverage for all test-definition and step-level changes.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.