Quality & QA
Automated QA: what to test before each release
Start with journeys whose failure stops an important task: signing in, purchasing, booking or accessing information. Useful tests reduce business uncertainty rather than just increasing test count.
1 — Prioritise by risk
List failure consequences: lost sales, blocked work, exposed information or recovery effort. Combine impact with usage and rate of change.
Start with a few complete journeys. In a booking application, check both the booking and its delivery to the team. A visible button is not enough.
2 — Choose the right test level
Calculations can often be tested without a browser. Integrations need contract checks. End-to-end tests verify a full journey.
Avoid duplicating all checks at all levels. Use smaller tests to isolate rules and browser tests for complete interactions.
3 — Make tests understandable
Playwright recommends user-visible behaviour and test isolation. This reduces dependence on internal implementation.
Use controlled data and actionable failures. Execution-order dependencies and changing production data undermine confidence.
- Prepare independent state.
- Use accessible selectors or stable contracts.
- Preserve reproduction evidence.
- Wait for conditions instead of arbitrary pauses.
4 — Test failure paths
Check insufficient permissions, invalid input, duplicates and unavailable services. A form confirmation alone does not prove delivery.
Include keyboard use, screen sizes and performance. Automated accessibility checks need complementary manual review.
5 — Agree release gates
Separate critical failures from warnings before release pressure arrives. Payment or access failures may block deployment; minor observations may become issues.
Assign maintenance and monitor after launch. Tests reduce risk but cannot guarantee no new bugs.