Error Handling and Error Pages

Why Error Handling Testing Matters #

Users will inevitably encounter errors — they will visit deleted pages, submit invalid forms, experience network timeouts, and trigger server failures. How your application handles these errors determines whether users stay or leave, whether they trust your product, and whether attackers can exploit error responses.

Error handling is one of the most frequently overlooked testing areas. Developers focus on the happy path, and errors are often tested last (if at all). This creates opportunities for QA to find impactful bugs.

HTTP Status Code Categories #

Key Status Codes to Test #

Testing Custom Error Pages #

404 Not Found Page #

The most common error users encounter. Test that:

• Visiting a non-existent URL shows a custom 404 page (not a generic server error)
• The page maintains site branding (header, footer, styles)
• Navigation is available to help the user find what they need
• A search bar is present
• Links to popular pages or the homepage are provided
• The correct 404 HTTP status code is returned (not 200)
• The page works in all supported languages

500 Internal Server Error Page #

• A friendly message is shown without technical details
• No stack traces, database errors, or file paths are visible
• Contact information or support link is provided
• The page suggests trying again later
• Monitoring/alerting triggers on 500 errors

403 Forbidden Page #

• Explains that access is denied without revealing why (do not say “this resource belongs to another user”)
• Suggests logging in if the user is not authenticated
• Provides a link to request access if applicable

Maintenance Page (503) #

• Clear message about maintenance in progress
• Expected return time if known
• Contact information for urgent issues
• Works without JavaScript (the app may be completely down)

Form Validation Error Testing #

Client-Side Validation #

Server-Side Validation #

Client-side validation can be bypassed. Test that:

• Disabling JavaScript and submitting forms still shows validation errors
• Submitting requests directly via API returns proper error messages
• Error messages do not reveal system internals

Error Message Quality #

Good error messages:

• Tell the user what went wrong
• Tell the user how to fix it
• Are positioned near the problematic field
• Are announced to screen readers (using aria-live or role="alert")
• Do not disappear too quickly

Bad error messages:

• “An error occurred” (too vague)
• “Error code: NullPointerException at UserService.java:142” (too technical)
• “Invalid input” (does not say what is invalid or how to fix it)

Security Considerations #

What Error Responses Must NOT Reveal #

Error Enumeration Prevention #

• Login errors should say “Invalid email or password” (not “Email not found” or “Wrong password”)
• Registration should not confirm whether an email is already in use
• Password reset should not confirm whether an email exists in the system

Exercise: Error Handling Audit #

Test the error handling of a web application across all major error categories.

Part 1: HTTP Error Pages #

Part 2: Form Validation #

Choose a form (registration, checkout, or contact) and test:

Part 3: Error Message Security #

Automation for Error Handling #

test('404 page returns correct status code', async ({ page }) => {
  const response = await page.goto('/this-page-does-not-exist');
  expect(response.status()).toBe(404);
  await expect(page.locator('nav')).toBeVisible(); // Navigation present
  await expect(page.locator('a[href="/"]')).toBeVisible(); // Home link
});

test('API errors do not leak internals', async ({ request }) => {
  const response = await request.get('/api/users/invalid-id');
  const body = await response.json();
  expect(body.message).not.toContain('Exception');
  expect(body.message).not.toContain('.java');
  expect(body.message).not.toContain('SELECT');
});

Key Takeaways #

• Error handling is frequently undertested — make it a standard part of your test plan
• Custom error pages should maintain site branding and provide navigation options
• Error messages must be user-friendly: explain the problem and how to fix it
• Never expose technical details in production error responses — stack traces, SQL, file paths
• Prevent information leakage through error responses (login enumeration, email existence)
• Verify that HTTP status codes match the error type (404 should return 404, not 200)