“Browser session” = an isolated browser context (BrowserContext) with its own separate cookies, localStorage, and sessionStorage.“Browser state” = the data stored within a session (login cookies, localStorage values, sessionStorage, etc.)
Dependency Types
Resume From
What it does: Test inherits browser state (login sessions, cookies, localStorage, sessionStorage) AND output data from the dependency. If the dependency completed successfully within the last 6 hours in the same environment, state is reused immediately. If older or failed, the dependency runs first.
Use when: You want to avoid repeated logins or expensive setup by reusing browser state from a previous test in the chain.
Wait For
What it does: Test waits for dependency to complete before starting. Receives output data (user IDs, resource names, URLs) from the dependency test, but starts with a fresh browser session-no shared cookies, localStorage, or login state.
Use when: You need execution order and data passing between different user contexts, or when tests need created data but not browser state. For workflows with the same user, use Resume From instead to avoid repeated logins.
Multiple Dependencies
A test can have multiple dependencies using both “Wait For” and “Resume From” relationships. If any dependency fails, all dependent tests are automatically skipped in that test run.
- Each test can have exactly one Resume From dependency (single browser state parent)
- Each test can have multiple Wait For dependencies (coordinate with many tests)
Examples
Resume From Example
Test structure:
- Login Test → 2. Create Order Test → 3. View Dashboard Test
All three tests share the same browser session, so the browser state (login cookies, localStorage, etc.) is preserved throughout the chain.
Wait For Example
Test structure:
- Create Team Test (outputs: team name “Marketing Team”)
- Add User to Team Test (receives: team name from Test 1)
Tests run sequentially, but each starts with a fresh browser session. Test 2 receives the output data from Test 1.
Browser Isolation & Parallel Execution
Each independent test chain runs in its own isolated browser session. Tests within a chain run sequentially and share browser state through “Resume From” dependencies, while different chains run in parallel with complete isolation.
Key points:
- Session A (Tests 1→2→3) runs sequentially with shared User 1 login
- Session B (Tests 4→5) runs sequentially with shared User 2 login
- Both sessions run in parallel, completely isolated from each other
- Test 5 waits for Test 3 to complete and receives output data, but maintains separate browser state
“Run Tests” Behavior: When you click “Run Tests” or trigger a test plan:
- Independent test chains run in parallel with isolated browser sessions
- Tests within a chain run sequentially, maintaining dependency order
- The system auto-scales up to ~100 concurrent agents to maximize parallelization
Multi-User Testing Scenarios
When testing features that require multiple users to be logged in simultaneously (e.g., collaboration, sharing, real-time features), create separate dependency chains for each user.
Pattern: Testing Collaborative Features
Scenario: Test that User 1 can create and share a visualization with User 2, who can then view it.
Structure:
User 1 Chain:
- Login as User 1 (root test, config:
[email protected])
- Create Visualization (Resume From: Login as User 1)
- Share Visualization (Resume From: Create Visualization)
User 2 Chain:
- Login as User 2 (root test, config:
[email protected])
- View Shared Visualization (Resume From: Login as User 2, Wait For: Share Visualization)
How It Works:
- User 1 chain runs in browser session A (all three tests share User 1’s login)
- User 2 chain runs in browser session B (both tests share User 2’s login)
- Sessions A and B are completely isolated from each other
- Both users remain logged in throughout their respective chains
- “Wait For” ensures User 2’s test waits for sharing to complete
- Output data (visualization link) passes from User 1 to User 2’s test
- Browser state (login sessions) remains isolated between chains
Key Points:
- Each user gets their own root login test with separate test configuration
- Use different test configurations for different user credentials
- Use “Resume From” within each user’s chain to maintain their session
- Use “Wait For” between chains to coordinate timing while keeping sessions isolated
- Tests in different chains run in parallel but maintain complete isolation
Each user needs their own root login test to ensure they get an isolated browser session. Depending on another user’s login will cause the tests to share a session, and one user will log out the other.
Application, Environment, and Domain Constraints
Browser state can only be shared via Resume From when tests run in the same Environment. This applies even across different Applications - Resume From works between Applications if both tests use the same Environment.
What Works vs. What Doesn’t
| ✅ Supported | ❌ Not Supported |
|---|
| Resume From within the same Environment | Resume From across different Environments |
| Output data passed between any tests, any Application, any Environment | Browser state transfer across different domains |
| Wait For dependencies across different Applications | Cookie/localStorage transfer between app.example.com and admin.example.com |
| Resume From across different Applications in the same Environment | Using Resume From between staging and production Environments |
Testing Across Applications
Use Wait For dependencies across Applications:
- Tests execute sequentially without browser state transfer
- Output data (user IDs, team names) passes between any tests
- Each test starts with fresh browser state on its target URL
Example:
Test 1: Create User (Frontend Application) → outputs userId
Test 2: Verify User (Admin App Application) → waits for Test 1, receives userId
- The system requires both tests to use the same Environment for state reuse
- Even if two Environments have similar URLs, Resume From won’t work across different Environments
- Tests in different Applications CAN use Resume From if they’re in the same Environment
Data Sharing Between Tests
QA.tech provides two mechanisms for passing data between dependent tests. Understanding when to use each helps you build effective multi-step test workflows.
Output Values (Recommended for Cross-Session Data)
Output values are data explicitly saved by a test during execution. They can be passed to any dependent test, regardless of whether the tests share a browser session.
| Aspect | Details |
|---|
| What’s shared | Text data: URLs, IDs, names, any string value |
| Works with | Both Wait For and Resume From dependencies |
| Persists across | Different browser sessions (cross-application) |
| When saved | Agent saves during test evaluation |
| How received | Agent sees values in context when test starts |
- Sharing URLs between tests that run in different browser sessions
- Passing created resource IDs (user IDs, order numbers) to verification tests
- Coordinating data between tests in different applications
Example: URL Sharing
- Test A creates a resource and the agent saves the URL in output values
- Test B has a Wait For dependency on Test A
- When Test B runs, the agent receives Test A’s URL and can navigate to it
Clipboard (Same Session Only)
Clipboard values are automatically saved when a test completes and restored when a Resume From dependent test starts in the same browser session.
| Aspect | Details |
|---|
| What’s shared | Clipboard content at test completion |
| Works with | Resume From dependencies only |
| Persists across | Same browser session chain only |
| When saved | Automatically when test finishes |
| How received | Clipboard is pre-populated when test starts |
- Copying and pasting within the same browser session chain
- Quick value transfer between sequential tests sharing a session
Example: Session Chain
- Test A logs in and copies a verification code to clipboard
- Test B uses Resume From dependency on Test A
- Test B can paste the verification code (same browser session, clipboard restored)
Comparison Table
| Mechanism | Cross-Application? | Cross-Session? | Automatic Save? |
|---|
| Output Values | Yes | Yes | No - agent saves explicitly |
| Clipboard | Only if same Environment | No - same session only | Yes - on test completion |
Common Patterns
Pattern 1: URL Sharing Across Applications
Scenario: Test in App 1 creates a resource, Test in App 2 needs to access it.
Test A (App 1): "Create order" → saves order URL in output values
↓ Wait For (data only)
Test B (App 2): "Verify order in admin" → receives URL, navigates to it
Pattern 2: Session Chain with Clipboard
Scenario: Multi-step workflow in the same session.
Test A: "Login and copy auth code"
↓ Resume From (session + clipboard)
Test B: "Paste auth code and verify"
Pattern 3: Combining Both Mechanisms
Scenario: Need both shared data AND session continuation.
Test A: "Create resource" → saves URL in output values
↓ Resume From (gets session + clipboard)
Test B: "Verify resource" → receives URL from output values, keeps login session
When a test has both Resume From and Wait For dependencies, it receives:
- Browser state (cookies, localStorage) from the Resume From dependency
- Output values from ALL dependencies (both Resume From and Wait For)
