Azure Pipelines CI/CD Integration

Azure Pipelines helps teams build, test, and deploy software as part of their CI/CD workflow. While Azure Pipelines provides visibility into build and test execution, QA teams often need those results to connect to requirements, defects, releases, reporting, and overall testing progress.

Azure Pipelines Integration with PractiTest allows automated test results become part of a centralized QA process. Teams can connect CI/CD execution data with manual testing, exploratory testing, requirements coverage, issue tracking, dashboards, reports, and release readiness.

By sending Azure Pipelines results to PractiTest, teams can centralize manual and automated testing activity and report automation results directly into PractiTest Test Sets and Runs

Prerequisites

Before configuring the integration, make sure you have:

• A PractiTest Project ID
• A PractiTest Test Set ID for automation results
• A PractiTest API token with the required permissions
• An Azure Pipelines pipeline that executes automated tests
• Test result files generated by your automation framework

How the Integration Works

There are two common ways to integrate Azure Pipelines with PractiTest.

Option 1: Post-Pipeline Reporting

In this setup, Azure Pipelines executes the automated tests first. After the execution is complete, a reporting script parses the generated result files and sends the results to PractiTest.

This is the most common integration model because it keeps the reporting logic separate from the test framework itself.

It also gives teams flexibility to decide:

• How tests are mapped
• Which Test Set should receive results
• Which custom fields should be updated
• Whether to report step-level execution
• Which files or artifacts should be attached

Option 2 – Real-Time Reporting

In this setup, the automation framework communicates directly with PractiTest during execution.

For example, a custom reporter or test hook can send results after each test completes.

This approach provides immediate visibility but usually requires deeper integration with the automation framework.

Using the PractiTest API

The PractiTest API allows Azure Pipelines and reporting scripts to create and update testing entities directly from automation executions.

Using the API, teams can:

• Create or update automated tests
• Add tests to the relevant Test Sets
• Report passed, failed, blocked, or skipped executions
• Send step-level execution details
• Attach logs, screenshots, or execution artifacts
• Populate custom fields such as environment, build number, branch, version, or component
• Connect Bamboo execution data to dashboards and reports in PractiTest

Auto Create a Run API

For most Azure Pipelines integrations, we recommend using the PractiTest Auto Create a Run API.

The Auto Create a Run endpoint simplifies automation reporting by automatically handling the creation flow when needed. Based on the information provided in the request, PractiTest can:

• Locate an existing test
• Create the test if it does not exist
• Locate the matching instance in the selected Test Set
• Create the instance if needed
• Create the automated run result

This makes the endpoint particularly useful for CI/CD integrations where automation frameworks focus on execution while PractiTest manages visibility, traceability, reporting, and release tracking.For detailed information about supported attributes, automatic test creation, execution steps, attachments, and reporting options, see the Auto Create a Run API documentation.

Mapping Azure Pipelines Data to PractiTest

Use this mapping to decide which pipeline data to include in your reporting script:

Azure Pipelines Data	PractiTest Destination
Test name	Test name
Test status	Run status
Failure message	Actual results or automated execution output
Test duration	Run duration
Build number	Custom field or execution output
Branch name	Custom field
Commit SHA	Custom field or execution output
Environment	Custom field
Release version	Version field or custom field
Logs	Run file or step file
Screenshots	Run file or step file
Test result XML or TRX	Run attachment or parsed step data
Azure Pipelines run URL	Execution output or custom field

Example: Reporting an Automated Run to PractiTest

{
 "data": {
   "type": "instances",
   "attributes": {
     "set-id": 12345,
     "run-type": "AutomatedRun",
     "run-duration": "00:00:18",
     "automated-execution-output": "Azure Pipelines build 20260519.4 completed. View the pipeline run in Azure DevOps."
   },
   "test-attributes": {
     "name": "Login with valid credentials",
     "test-type": "ApiTest",
     "description": "Automated test reported from Azure Pipelines"
   },
   "steps": {
     "data": [
       {
         "name": "Run automated login test",
         "expected-results": "The user should be logged in successfully.",
         "actual-results": "The automated test passed in Azure Pipelines.",
         "status": "PASSED"
       }
     ]
   }
 }

This example sends an automated execution result into PractiTest. The same approach can be extended to include failed steps, custom fields, files, build metadata, environment details, or links back to the Azure Pipelines run.

Example: Azure Pipelines YAML

steps:
 - script: |
     npm install
     npm test -- --reporter junit --reporter-options output=test-results/junit.xml
   displayName: "Run automated tests"

 - task: PublishTestResults@2
   inputs:
     testResultsFormat: "JUnit"
     testResultsFiles: "test-results/*.xml"
   condition: always()
   displayName: "Publish test results to Azure Pipelines"

 - script: |
     python3 scripts/report_to_practitest.py \
       --results "test-results/*.xml" \
       --project-id "$(PRACTITEST_PROJECT_ID)" \
       --set-id "$(PRACTITEST_SET_ID)" \
       --token "$(PRACTITEST_API_TOKEN)" \
       --build-id "$(Build.BuildId)" \
       --build-number "$(Build.BuildNumber)" \
       --branch "$(Build.SourceBranchName)"
   condition: always()
   displayName: "Report results to PractiTest"

The reporting script referenced above (report_to_practitest.py) is not provided out of the box. You will need to write or adapt a script that parses your test result files and calls the PractiTest API.

The script can parse test result files generated during the Azure Pipelines run and send each test result to PractiTest. Teams can adapt the implementation to match their automation framework, naming conventions, custom fields, and reporting requirements.

Using Pipeline Variables

We recommend storing PractiTest configuration values as secured Azure Pipelines variables. Common variables include:

• PRACTITEST_PROJECT_ID
• PRACTITEST_SET_ID
• PRACTITEST_API_TOKEN
• PRACTITEST_BASE_URL

The reporting script can also use Azure Pipelines build variables such as:

• Build Number
• Build ID
• Branch Name
• Commit SHA
• Pipeline Run URL

These values can be stored in PractiTest as execution output or custom field values.

Why Send Azure Pipelines Results to PractiTest?

Azure Pipelines shows whether a build or test execution passed. PractiTest helps teams understand what those results mean in the context of testing progress, requirements coverage, defects, and release readiness.

By sending Azure Pipelines results into PractiTest, teams can:

• Understand which tests were executed
• Identify what failed
• Track affected requirements
• Link execution results to defects
• Measure automation coverage
• Include CI/CD execution data in dashboards and reports
• Improve release visibility and decision-making

Best Practices

To keep the integration maintainable, start with a focused implementation and expand gradually.

• Use a dedicated PractiTest Test Set for Azure Pipelines automation
• Store the PractiTest API token as a secured pipeline variable
• Use stable test names or test IDs to avoid duplicate tests
• Include build number, build ID, branch, and pipeline URL in the PractiTest run
• Use custom fields for environment, version, component, commit SHA, or pipeline name
• Report results even when automated tests fail
• Add retry logic for large test suites or temporary API errors
• Start with one automation suite before expanding to additional pipelines