---
title: "Run agent-qa against a pull request preview environment"
description: "Prepare a preview target, identify the deployed revision, seed isolated data and distinguish application failures from missing environment dependencies."
canonical_url: "https://vostride.com/agent-library/software-factory/qa-for-preview-environments.md"
md_url: "https://vostride.com/agent-library/software-factory/qa-for-preview-environments.md"
content_kind: "guide"
topic: "software-factory"
---

# Run agent-qa against a pull request preview environment

A preview deployment provides a useful target only when the test can identify the build and reach its required dependencies. Record the preview URL, candidate revision, fixture revision and feature flags before execution. Do not assume that an HTTP success response means the intended application build is ready.

## Prepare the target

Configure a web target with the preview URL in the project's agent-qa configuration. Reuse the existing model and browser configuration where appropriate; keep deployment credentials outside test text. The [global configuration reference](/docs/agent-qa/configuration/global-config.md) describes target selection, and the [agent quickstart](/docs/agent-qa/agent-quickstart.md) supplies a complete setup path.

Use the preview platform's authorized access mechanism if the deployment is protected. Confirm the application's own login works separately from deployment access. A cached authenticated session can conceal an identity-provider callback that points at another environment.

## Make dependencies explicit

Create test-owned records with a run-specific namespace. Confirm that background jobs, email fixtures, object storage and sandbox service callbacks reach the same environment as the browser. A UI flow may save successfully while its notification worker still points to a shared staging queue.

For destructive or stateful flows, use resettable fixtures. Keep external service configuration and cleanup owned by the deployment or test harness rather than inventing browser steps to control infrastructure.

## Verify and report

Run the focused acceptance test only after readiness checks succeed. Capture evidence identifying the candidate build and the expected fixture. If a dependency is absent, report an environment failure with the missing service; do not record a product pass because the test never reached its main assertion.

After the run, remove test-owned data and retain the result even if the preview will be deleted. Record enough context to reproduce the same application revision in another environment. A later rerun against a moving staging URL cannot by itself verify the original preview.

[Release regression recipes](/agent-library/release-regression.md) · [Hooks for fixtures](/docs/agent-qa/guides/hooks.md)
