A large test count does not tell you whether the next release will break a customer's work. Start by naming the actions that must remain dependable, then protect those actions at the boundary users and other systems actually consume. For an older ASP.NET application, browser and HTTP checks can establish a useful baseline without first replacing the application framework.
Choose a business slice
List the workflows a release could disrupt. For each, record who performs it, the data it changes, the consequence of failure, recent changes, and the person who can confirm correct behavior. Select an initial slice small enough to understand and maintain.
- Include a successful path, a rejected or invalid action, and an authorization boundary.
- Separate observed legacy behavior from intended behavior. Record known defects instead of silently turning them into requirements.
- Agree which browsers, roles, tenants, and integrations matter for this slice.
Make the test repeatable
Use an isolated test environment and synthetic data with a known reset strategy. Playwright recommends independent tests, locators based on user-facing attributes or explicit test contracts, and assertions that wait for the expected condition. Prefer those patterns to fixed delays and long CSS selectors.
- Create or seed the exact data a test needs; avoid sharing a mutable customer or order between parallel tests.
- Assert the business result: the saved value, resulting status, relevant API response, or absence of an unauthorized change.
- Stub an external dependency when testing your own response to it, and keep separate contract checks for the real integration.
Make a failure actionable
Assign a test owner and capture the application version, environment, fixture identifier, and failure evidence. Playwright traces can expose action timing, DOM snapshots, and network activity. Keep these artifacts access-controlled because they may contain application data.
- Record retries as instability evidence; a passing retry should not erase the first failure.
- Keep an explicit list of quarantined tests with an owner, reason, and next action.
- Exclude saved browser authentication state from source control; it can contain reusable session credentials.
- Demonstrate that an assertion detects a deliberate, safe change to the expected result before relying on it as a release check.
Illustrative workflow: amend a customer contact
An authorized operator changes a synthetic customer's phone number. A read-only operator attempts the same change.
Acceptance criteria
- The authorized change survives a reload and appears in the agreed audit record.
- An invalid phone number returns the agreed validation message and does not change the stored value.
- The read-only operator cannot perform the update through either the UI or the relevant API.
- Each test runs independently against its own fixture and can be reproduced from its recorded inputs.
The artifacts to keep
- Workflow-and-risk map
- Automated checks in the client's repository
- CI run evidence and failure triage notes
- Coverage gaps, owners, and a maintenance guide
Limits to keep visible
- Browser checks do not replace lower-level tests, load testing, accessibility review, or security assessment.
- A green suite demonstrates only the scenarios and environments it actually exercises.
Use the readiness check to identify which prerequisites are missing before expanding automation.
Primary sources
- Playwright: Best practicesTest isolation, user-visible behavior, resilient locators, and web-first assertions.
- Playwright: Trace viewerDiagnostic traces, CI trace options, DOM snapshots, and network inspection.
- Playwright: AuthenticationAuthenticated browser state and the sensitivity of saved authentication data.
Co-written by Adnan Rafiq and ChatGPT. ChatGPT assists with research, drafting, and source checks; the engineering direction comes from Adnan. Examples are illustrative unless an article explicitly provides executed results. These are working methods, not customer case studies or guaranteed outcomes.