External test suites

External test suites let you run scenarios outside your primary workflow authoring process and review the results in Cofactor. Each run keeps scenario-level evidence, including video and captured browser URLs, so you can investigate failures and track test health over time.

01When to use external test suites

Use an external test suite when you need to validate a product with repeatable browser-based scenarios, monitor behavior on a schedule, or bring results from an external testing process into Cofactor.

External suites are useful for:

• Regression checks that run after a release or on a recurring schedule.
• End-to-end scenarios that cover important user journeys.
• Failure investigation where a video and the browser URL provide more context than a pass or fail status.
• Team notifications when a scheduled run produces failures or requires review.

02Core concepts

External suites and scenarios

An external test suite is a collection of related scenarios. A scenario describes one test journey and its expected outcome, such as signing in, completing a checkout flow, or verifying a key page.

Keep scenarios focused on one behavior or user journey. Smaller scenarios make failures easier to isolate and make their videos, URLs, and results easier to review.

Runs and results

A run is one execution of an external test suite. The run summarizes the suite outcome and contains the individual result for each scenario.

Use the run status to identify whether the suite completed successfully. Open scenario results to inspect the detailed evidence. A failed result indicates that the scenario did not meet its expected outcome; use the available video and captured browser URL to reproduce and diagnose the failure.

03Configure an external test suite

Create a suite for a stable group of scenarios, then define the order and expected outcome for each scenario in the external testing workflow. Provide the environment, credentials, and other access required for the scenarios to reach the product areas they test.

When configuring a suite:

1. Give the suite a descriptive name that identifies its purpose or coverage area.
2. Add scenarios with clear names and a specific expected result.
3. Configure the environment and access needed for each scenario.
4. Choose a schedule when the suite should run automatically. Use a cadence that matches the risk and change rate of the tested area.
5. Save the suite and run it once manually to confirm that the scenarios and access settings are correct.

Browser capture is available for browser-based external tests, and results retain the captured browser URL for each scenario. You do not need to enable capture separately for individual runs. Review the first run before relying on the suite as a scheduled check.

04Review test results

Open a completed run to see the overall result and the status of each scenario. Start with failed scenarios, then review their evidence and compare them with earlier runs to determine whether the issue is new, intermittent, or recurring.

Use the scenario result to confirm the test's outcome, then open the available evidence for a closer investigation. Preserve the run context when sharing a failure with the team so others can review the same scenario and captured artifacts.

Scenario videos

Each browser-based scenario can include its own video. Scenario-level video helps you see the actions leading to a failure without searching through a full-suite recording.

Use the video to:

• Confirm the point where the scenario diverged from the expected flow.
• Distinguish a product failure from an authentication, navigation, or timing problem.
• Share a concise reproduction of the failed scenario with the owner of the affected area.

Video availability depends on the scenario producing browser activity. If a scenario has no video, use its status, captured URL, and other available result details to continue the investigation.

Captured browser URLs

External test results retain the browser URL captured during a scenario. Open the URL to identify the page or route involved in the result and compare it with the scenario's expected destination.

Treat captured URLs as diagnostic evidence, not as a replacement for access controls. A URL may require the same environment, permissions, or authentication as the original test run. Avoid sharing a captured URL outside the people who are authorized to access that environment.

Pagination and run history

Results are paginated so you can review large suites and run histories without loading every result at once. Move through the available result pages to inspect all scenarios in a run, and use the run history to compare current behavior with previous executions.

Review the newest run first when responding to an alert. Then compare earlier runs to look for repeated failures, intermittent behavior, or a change that aligns with a recent release. Record the relevant run and scenario when escalating an issue.

05Alerts and notifications

Schedule alerts for an external test suite when the team needs to know about failures without checking the results page manually. Configure notifications around the suite's schedule so the alert reaches the appropriate owners after a run completes.

Use scheduled alerts to:

• Notify a team when a recurring regression check fails.
• Assign ownership for failures in critical user journeys.
• Keep release or operations channels informed about test health.

Define who should receive the alert and what action they should take. Avoid alerting an entire team for low-risk suites; route notifications to the people who can investigate or correct the failure. When an alert arrives, open the associated run and review the failed scenario's video and captured browser URL.

06Best practices

• Group scenarios by product area, risk, or release responsibility rather than creating one large, unrelated suite.
• Give every scenario a clear expected outcome and keep it focused on one user journey.
• Run a suite manually after changing its scenarios, environment, credentials, or schedule.
• Use scenario videos and captured URLs together to shorten failure triage.
• Review paginated results and recent run history instead of relying only on the suite-level status.
• Schedule alerts for critical suites and assign a clear owner for responding to failures.
• Protect captured URLs, videos, and test credentials as environment-specific test evidence.
• Investigate repeated failures across multiple runs before treating an intermittent result as resolved.

07Related

• Workflows for repeatable automation and workflow-based testing.
• Test runs for reviewing execution status and run history.
• Alerts and notifications for notification and escalation practices.