Error Handling: Graceful Recovery and User Guidance
all
Persona: qa-tester
Touchpoint: all pages and endpoints
Preconditions
- Error handling middleware configured
- Error pages exist (404, 500, etc)
Steps
| # | Action | Expected Result |
|---|---|---|
| 1 | Trigger a 404 error (visit /nonexistent-page) | 404 page shown. Clear message. Link back to home visible. |
| 2 | Trigger a 500 error (simulated API failure) | Error message shown (not technical stack trace). 'Try again' or 'Contact support' CTA visible. |
| 3 | Trigger network timeout (slow API) | Loading spinner visible. After 10s, timeout message with 'Retry' button. |
| 4 | Trigger form validation error | Error message shown inline with field. Clear description of issue. |
| 5 | Trigger API rate limiting (429) | Error message: 'Too many requests. Please wait before trying again.' |
| 6 | Trigger missing data (404 from API) | User-friendly message. Not technical 'resource not found'. |
| 7 | Trigger checkout failure (declined card) | Error message explains why. Link to update payment method or try again. |
| 8 | Test error logging | Errors logged to monitoring system (Sentry, LogRocket). Developers can debug. |
Known Failure Modes
- User sees technical stack trace — unprofessional, scary
- No error message — user confused about what went wrong
- No recovery path — user stuck, can't retry
- Errors not logged — developers can't debug production issues
References
- Playwright spec:
e2e (error validation) - Code files:
Notes
Tests error handling and recovery. Users will encounter errors — how you handle them determines whether they retry or give up. Must show clear messages, offer recovery paths, and log errors for debugging. Poor error UX = churn.