Hi everyone,
We often get questions about how teams can use PractiTest as the control layer for automation, while letting their existing automation framework handle execution.
Below is an example flow that shows how you can run automated tests using the PractiTest API, with no manual triggering once everything is set up.
This is not a prescribed implementation, just a practical reference you can adapt to your own stack.
High-Level Concept
PractiTest is used as the orchestration and control layer, while the automation framework is responsible for:
-
Detecting which test sets should be executed
-
Mapping PractiTest test IDs to automation scripts
-
Running the tests
-
Reporting results and artifacts back into PractiTest
Preconditions
Before automation can run:
-
Tests must already be automated.
-
Each PractiTest test must be mapped to a corresponding automation script.
-
Test sets must include only tests that are eligible for automation.
Test Set Configuration
Each test set includes a custom checkbox field called “Run Automatically”.
-
When checked, the test set is considered queued for execution
-
When unchecked, the test set is ignored by the automation framework
This field is used to create a PractiTest filter that represents the automation execution queue.
Execution Flow
1. Creating the Test Set
A tester or manager:
-
Creates a test set
-
Adds the relevant automated tests
-
Checks the “Run Automatically” field
At this point, the test set becomes visible to the automation framework as it is placed within the filter housing all the sets to be run by it.
2. Detecting Test Sets to Run
The automation framework:
-
Polls PractiTest (e.g., once per minute, or immediately after finishing a run)
-
Uses the PractiTest API to retrieve all test sets matching the automation filter
-
Processes test sets in FIFO order, based on last modification time
To prevent duplicate execution:
- As soon as a test set is picked up, the framework unchecks the “Run Automatically” field via the API
3. Executing the Tests
For each test set:
-
All test instances are retrieved via the API
-
The framework determines which automation script corresponds to each test
-
Tests are executed:
-
Sequentially or in parallel
-
Based on a test-set-level attribute
-
4. Reporting Results
As each test completes, the automation framework:
-
Updates the test instance result in PractiTest
-
Uploads relevant artifacts (logs, screenshots, reports, etc.)
-
Preserves full traceability between:
-
Test definition
-
Execution
-
Results
-
Evidence
-
5. Continuous Processing
Once a test set is fully handled:
-
The automation framework queries PractiTest again
-
If new test sets are queued, execution continues
-
If not, the framework waits for the next polling cycle
Key Benefits of This Approach
-
No manual triggering of automation runs
-
PractiTest remains the single source of truth
-
Clear execution queue and status visibility
-
Full result traceability inside PractiTest
-
Framework-agnostic (works with any automation stack)