Browser QA

Original skill by ECC. Used with clear credit under its open-source license.

When to Use

Use this skill when:

• A feature is on a test or preview site.
• You need to check a full page.
• You want to test before a release.
• You review a change to the user interface.
• You need to test phone and tablet views.
• You need to check access for people with disabilities.

Before You Start

Ask for these items if they are not known:

• The page URL.
• The pages and user tasks to test.
• Test login details, if needed.
• The allowed test data.
• Saved images to compare, if any.

Do not use real payment details. Do not send real orders, emails, or messages unless the user says it is safe. Do not delete or change live data.

If a page needs a login and no test login is ready, test all public pages. Mark the login tests as blocked.

Use an approved browser tool, such as Playwright, Puppeteer, or Claude in Chrome.

Phase 1: Basic Checks

1. Open the target URL.
2. Wait until the main page content is ready.
3. Check for browser errors.
4. Ignore known noise from ads, stats tools, and other outside tools. List what you ignored.
5. Check page calls for 4xx and 5xx errors.
6. Ignore calls that were stopped on purpose. Note them in the report.
7. Take a top-of-page image at these widths:
   • Phone: 375 px
   • Tablet: 768 px
   • Desktop: 1440 px
8. Check these speed goals when the browser tool can read them:
   • LCP under 2.5 seconds
   • CLS under 0.1
   • INP under 200 ms
9. If a speed value cannot be read, mark it as not tested. Do not guess.

Run each speed test more than once when time allows. Slow networks and cold starts can change the result.

Phase 2: User Actions

Test the main tasks first.

1. Open each main menu link.
2. Check that each link goes to the right page.
3. Test forms with safe and valid data.
4. Check the success message or next page.
5. Test empty, bad, and very long form values.
6. Check that each error is clear and shown near the right field.
7. Test login, a private page, and logout when a test login is ready.
8. Test key tasks, such as search, sign-up, setup, cart, and checkout.
9. Test the Back button after key steps.
10. Test loading, empty, error, and success states when they can be reached.
11. Stop before any step that could charge money, publish data, or harm live data.

For a link that opens a new tab, check the new tab. Then return to the first tab.

Phase 3: Page View Checks

Take full-page images of key pages at:

• 375 px
• 768 px
• 1440 px

For each size, check for:

• Text cut off or hidden.
• Images outside the page.
• Sideways page scroll.
• Items that cover each other.
• Missing buttons, text, or images.
• Menus that cannot open or close.
• Pop-ups that cannot be closed.
• Fixed bars that hide page content.
• Text or controls that are too small to use.

Compare with saved images when they exist. Flag:

• A move of more than 5 px.
• A missing item.
• A new item that should not be there.
• A clear change in size, space, color, or font.

Do not call a change a bug if it was planned. If the goal is not known, mark it for review.

Test dark mode if the site has it. Test zoom at 200 percent on at least one key page.

Phase 4: Access Checks

Run axe-core or a similar tool on each key page when it is ready.

Check for:

• WCAG A and AA issues.
• Low color contrast.
• Images with no useful text name.
• Form fields with no label.
• Buttons or links with no clear name.
• More than one item with the same ID.
• A bad heading order.
• Missing page areas, such as main or nav.
• Focus that is hard to see.
• Focus that moves in the wrong order.

Use only the keyboard to:

1. Move through all controls with Tab and Shift+Tab.
2. open links and buttons with Enter or Space.
3. Open and close menus and pop-ups.
4. Close pop-ups with Escape.
5. Finish one key task.

Make sure focus does not get stuck. After a pop-up closes, focus should go back to the control that opened it.

A tool scan does not find every access issue. Report both tool results and hand checks.

Failed or Blocked Tests

Retry a failed step once if the cause may be a slow page or tool fault.

For each failed or blocked test, save:

• The page URL.
• The page size.
• The exact test step.
• What should have happened.
• What happened instead.
• An image, browser error, or failed page call.
• Whether the problem happens again.

Never mark a skipped test as passed.

Output Format

## QA Report: [URL]
Tested: [date and time]
Build: [build name or commit, if known]
Browser: [name and version]
Result: [PASS, FAIL, or BLOCKED]

### Summary
- Passed: [count]
- Failed: [count]
- Blocked: [count]
- Not tested: [count]

### Basic Checks
- PASS: The page loads.
- FAIL: `/api/profile` returns 500.
- NOT TESTED: INP could not be read.
- Images: [file names or links]

### User Actions
- PASS: Main menu links open the right pages.
- PASS: The form shows errors for bad data.
- FAIL: The phone menu does not open.

### Page View Checks
- PASS: The desktop page has no overlap.
- FAIL: The main image goes past the phone screen.
- REVIEW: The title moved 8 px from the saved image.

### Access Checks
- FAIL: 1 WCAG AA color contrast issue.
- PASS: 0 WCAG A issues.
- FAIL: Keyboard focus gets stuck in the sign-up pop-up.

### Bugs
#### BUG-1: Phone menu does not open
- URL: [page URL]
- Page size: 375 x 812
- Steps:
  1. Open the page.
  2. Select the menu button.
- Expected: The menu opens.
- Actual: Nothing happens.
- Proof: [image, error, or failed page call]

### Blocked Tests
- Login test: No test login was ready.

Example Use

Request:

Test https://preview.example.com on phone, tablet, and desktop.
Check sign-up, login, search, and the main menu.
Do not send email or make a real payment.

Run:

1. Open the home page at 375 px, 768 px, and 1440 px.
2. Check browser errors and failed page calls.
3. Save top and full-page images.
4. Test all main menu links.
5. Test sign-up with safe test data. Stop before email is sent.
6. Test login with the test login.
7. Search for a known item and a missing item.
8. Run access checks.
9. Test one full task with only the keyboard.
10. Write the report with proof for each failure.

Use With Other Skills

• Use /benchmark for a deeper speed test.
• Use /canary-watch for checks after a deploy.
• Add this skill to pull request checks for changes to the user interface.