---
title: "Verify a candidate workflow persists across browser engines"
description: "Test a sandbox record authored in one browser and read in another, separating browser-specific interaction failures from shared data persistence."
canonical_url: "https://vostride.com/agent-library/release-regression/cross-browser-saved-workflow.md"
md_url: "https://vostride.com/agent-library/release-regression/cross-browser-saved-workflow.md"
content_kind: "recipe"
topic: "release-regression"
---

# Verify a candidate workflow persists across browser engines

Test a sandbox record authored in one browser and read in another, separating browser-specific interaction failures from shared data persistence.

## Risk

Two browser smoke pages can pass without exercising any meaningful product state. Transfer one uniquely identified record through a real workflow and compare the same data in independently prepared browser sessions.

## Fixtures

- An owned candidate web sandbox with separate configured Chromium and WebKit test sessions and a disposable shared test account.
- A record editor with multiline text and a nondefault selection, plus a unique run marker and expected values.
- A read-only record oracle; each test uses a documented browser configuration and a valid independently verified web session where authentication is required.

## Steps

1. In the Chromium fixture, create the record with the unique title, multiline body, and nondefault selection, then verify its reopened detail and capture its immutable identifier.
2. In the prepared WebKit fixture, verify the test account identity, find that identifier, and verify all three stored values.
3. Edit only the selection in WebKit, save, and verify its reopened detail reflects the change without losing text.
4. Return to the Chromium fixture, refresh the record, and verify the new selection and unchanged text; inspect the independent oracle for one record and the two intended accepted revisions.

## Expected results

- Both browser engines can complete their assigned meaningful interaction and read the shared record.
- The second browser edit preserves fields authored by the first.
- Persistent data contains one record and only the two intended content revisions.

## False-pass traps

- Opening two landing pages does not establish cross-browser editor behavior.
- Using separate same-title records in each browser avoids verifying shared persistence.

## Cleanup

- Delete the disposable record and close the two prepared browser sessions.

## Use with agent-qa

Adapt this test design to your application's acceptance criteria and configured target using the [recipe execution guide](/agent-library/software-factory/turn-a-recipe-into-an-agent-qa-test.md). External fixture setup and non-UI checks require your own supported hooks or test tooling. Validate the authored test, execute it, and inspect the completed evidence; this recipe is not a recorded test result.

## References

- [agent-qa first test](/docs/agent-qa/guides/first-test.md)
- [agent-qa hooks](/docs/agent-qa/guides/hooks.md)
- [agent-qa test](/docs/agent-qa/configuration/test.md)

- [Release regression QA recipes](/agent-library/release-regression.md)
- [Software factory QA library](/agent-library.md)