Project 11: Browser Automation Skill - Web Testing Assistant
Project 11: Browser Automation Skill - Web Testing Assistant
Build a skill that leverages Chrome MCP to automate web testing: navigate, fill forms, click buttons, take screenshots, and verify page content.
Quick Reference
| Attribute | Value |
|---|---|
| Difficulty | Advanced |
| Time Estimate | 1-2 weeks |
| Language | Markdown + JavaScript |
| Prerequisites | Projects 9-10 completed, Chrome MCP enabled, web development basics |
| Key Topics | Browser automation, MCP tools, DOM selectors, E2E testing |
| Knowledge Area | Skills / Browser Automation / Testing |
| Main Book | “Testing Web APIs” by Mark Winteringham |
1. Learning Objectives
By completing this project, you will:
- Integrate skills with MCP tools: Learn how skills can orchestrate browser automation via Chrome MCP
- Master browser automation patterns: Navigate, interact, wait, and verify in automated tests
- Write reliable selectors: Create CSS and XPath selectors that don’t break easily
- Implement wait strategies: Handle dynamic content and async operations
- Capture test evidence: Take screenshots and gather logs for debugging
- Create reusable test templates: Build patterns for common testing scenarios
2. Theoretical Foundation
2.1 Skills + MCP Tools
Skills can invoke any tool Claude has access to, including MCP (Model Context Protocol) tools. Chrome MCP provides browser automation capabilities:
┌─────────────────────────────────────────────────────────────────────────┐
│ SKILL + MCP INTEGRATION │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ User: "Test the login flow on staging" │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ web-testing │ Skill discovered, SKILL.md loaded │
│ │ skill │ │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ SKILL INSTRUCTIONS │ │
│ │ │ │
│ │ "1. Navigate to login URL" │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ mcp__claude-in-chrome__navigate │ │
│ │ │ │ │
│ │ "2. Find username field" │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ mcp__claude-in-chrome__find │ │
│ │ │ │ │
│ │ "3. Fill form fields" │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ mcp__claude-in-chrome__form_input │ │
│ │ │ │ │
│ │ "4. Click submit" │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ mcp__claude-in-chrome__computer (click action) │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
2.2 Chrome MCP Tool Family
The Chrome MCP extension provides these tools:
| Tool | Purpose |
|---|---|
mcp__claude-in-chrome__navigate |
Go to URLs, back/forward |
mcp__claude-in-chrome__read_page |
Get accessibility tree of page |
mcp__claude-in-chrome__find |
Find elements by natural language |
mcp__claude-in-chrome__form_input |
Set values in form fields |
mcp__claude-in-chrome__computer |
Click, type, screenshot, scroll |
mcp__claude-in-chrome__tabs_context_mcp |
Manage browser tabs |
mcp__claude-in-chrome__get_page_text |
Extract text content |
2.3 The Testing Pyramid and E2E Tests
┌─────────────────────────────────────────────────────────────────────────┐
│ TESTING PYRAMID │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ /\ │
│ / \ │
│ / \ │
│ / E2E \ <── This project: Browser tests │
│ /--------\ Slow, but tests real flow │
│ / \ │
│ / Integration \ API tests, component tests │
│ /--------------\ │
│ / \ │
│ / Unit Tests \ Fast, isolated tests │
│ /────────────────────\ │
│ │
│ E2E (End-to-End) tests: │
│ - Test complete user flows │
│ - Use real browser │
│ - Slowest but highest confidence │
│ - Where this skill operates │
│ │
└─────────────────────────────────────────────────────────────────────────┘
2.4 Selector Strategies
Good selectors are stable and readable:
┌─────────────────────────────────────────────────────────────────────────┐
│ SELECTOR RELIABILITY SPECTRUM │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ FRAGILE (Avoid) STABLE (Prefer) │
│ ─────────────── ────────────── │
│ │
│ div > div > div > span [data-testid="login-btn"] │
│ │ │ │
│ │ Path-based selectors │ Test IDs are explicit │
│ │ break with layout changes │ and stable │
│ │ │ │
│ .css-1a2b3c button[type="submit"] │
│ │ │ │
│ │ Generated class names │ Semantic selectors │
│ │ change on rebuild │ match intent │
│ │ │ │
│ #element_12345 input[name="username"] │
│ │ │ │
│ │ Dynamic IDs │ Form field names are │
│ │ change each render │ usually stable │
│ │
│ SELECTOR PRIORITY: │
│ 1. data-testid, data-cy, data-test (added for testing) │
│ 2. Semantic attributes (type, name, role) │
│ 3. Text content (button text, labels) │
│ 4. CSS classes (only if semantic) │
│ 5. Position/hierarchy (last resort) │
│ │
└─────────────────────────────────────────────────────────────────────────┘
2.5 Wait Strategies
Timing issues are the #1 cause of flaky tests:
┌─────────────────────────────────────────────────────────────────────────┐
│ WAIT STRATEGIES │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ BAD: Fixed waits GOOD: Conditional waits │
│ ───────────────── ─────────────────── │
│ │
│ // Wait 3 seconds // Wait for element to appear │
│ await sleep(3000); await waitForElement('#result'); │
│ │
│ Problems: Benefits: │
│ - Too slow if element appears fast - Proceeds when ready │
│ - Too fast if element takes longer - Fails fast if never appears │
│ - Wastes time on every run - No unnecessary waiting │
│ │
│ WAIT CONDITIONS: │
│ │
│ 1. Element visible - Wait until element is in DOM and visible │
│ 2. Element clickable - Visible + enabled + not obscured │
│ 3. URL changed - After navigation or form submit │
│ 4. Text appears - Success message, error message │
│ 5. Element disappears - Loading spinner gone, modal closed │
│ 6. Network idle - All XHR/fetch requests complete │
│ │
└─────────────────────────────────────────────────────────────────────────┘
2.6 Test Evidence
Capture proof of what happened:
| Evidence Type | When to Capture | Purpose |
|---|---|---|
| Screenshots | Before/after key actions | Visual proof, debugging |
| Console logs | On errors | JavaScript errors |
| Network logs | API calls | Verify backend communication |
| Page text | After navigation | Verify content loaded |
| Timing data | Throughout | Performance analysis |
3. Project Specification
3.1 What You Will Build
A web testing skill that:
- Navigates to target URLs and verifies page load
- Fills forms with test data
- Clicks buttons and follows flows
- Takes screenshots as evidence
- Verifies expected outcomes
- Reports comprehensive test results
3.2 Functional Requirements
- Navigation:
- Navigate to any URL
- Handle redirects
- Wait for page load
- Form Interaction:
- Fill text inputs, selects, checkboxes
- Handle password fields (masking in output)
- Clear existing values before filling
- Actions:
- Click buttons and links
- Handle confirmations/alerts
- Wait for resulting navigation
- Verification:
- Check for expected text/elements
- Verify URL after navigation
- Detect error messages
- Evidence:
- Screenshot at key moments
- Log timing information
- Report success/failure with details
3.3 Non-Functional Requirements
- Reliability: Tests should be deterministic (no flakiness)
- Speed: Use efficient waits, not fixed delays
- Clarity: Output explains what happened and why
- Safety: Never store/transmit real credentials
4. Real World Outcome
When you complete this project, here’s exactly what you’ll experience:
You: Test the login flow on staging
Claude: [Invokes web-testing skill]
I'll test the login flow. Let me navigate to your staging environment...
Navigating to https://staging.example.com/login
Screenshot saved: 01_login_page.png
Filling login form...
- Username: test@example.com (input masked in output)
- Password: ********* (input masked in output)
- Clicking "Sign In" button...
Waiting for navigation...
Login successful!
Screenshot saved: 02_dashboard.png
Verifying dashboard elements:
- Welcome message: FOUND "Welcome, Test User"
- Navigation menu: FOUND (5 items present)
- User avatar: FOUND
Test Results:
-------------------------------------------
Login Flow: PASSED
Steps Completed:
1. Navigate to login page 0.8s
2. Fill username field 0.1s
3. Fill password field 0.1s
4. Click submit button 0.1s
5. Wait for navigation 1.2s
6. Verify dashboard 0.3s
Total Duration: 2.6s
Evidence:
- Screenshots: 01_login_page.png, 02_dashboard.png
- Test data used: test@example.com
- Final URL: https://staging.example.com/dashboard
Would you like me to test another flow or investigate anything?
5. The Core Question You’re Answering
“How can I create a skill that orchestrates browser automation for web testing, combining Claude’s reasoning with real browser interaction?”
This project teaches you:
- How skills can use MCP tools for external capabilities
- Browser automation patterns that work reliably
- How to structure test workflows declaratively
- The intersection of AI assistance and automation
6. Concepts You Must Understand First
6.1 Chrome MCP Tools
| Concept | Questions to Answer | Reference |
|---|---|---|
| Available tools | What MCP tools exist for browser control? | Claude system prompt |
| Tab management | How do you get/use tab IDs? | tabs_context_mcp tool |
| Element finding | How do you locate elements on the page? | find, read_page tools |
| Interactions | How do you click, type, scroll? | computer tool |
6.2 Web Testing Patterns
| Concept | Questions to Answer | Reference |
|---|---|---|
| Page Object Model | How do you organize test code? | Testing books |
| Wait strategies | How do you handle async content? | This guide, section 2.5 |
| Selectors | What makes a selector reliable? | This guide, section 2.4 |
| Test data | How do you manage test credentials? | Never hardcode production creds |
6.3 DOM and Selectors
| Concept | Questions to Answer | Reference |
|---|---|---|
| CSS selectors | How do you select by class, ID, attribute? | MDN Web Docs |
| Semantic selectors | What attributes are stable? | type, name, role, data-* |
| Element states | How do you know if something is clickable? | Accessibility tree |
7. Questions to Guide Your Design
7.1 What Tests Should the Skill Support?
Consider common web testing scenarios:
| Test Type | Example | Complexity |
|---|---|---|
| Login flow | Fill credentials, verify dashboard | Medium |
| Form submission | Complete multi-step form | High |
| Navigation | Click links, verify pages | Low |
| Search | Enter query, verify results | Medium |
| CRUD operations | Create, read, update, delete items | High |
7.2 How to Make Tests Reliable?
Build reliability into your skill:
┌─────────────────────────────────────────────────────────────────────────┐
│ RELIABILITY CHECKLIST │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ Before each action: │
│ [ ] Wait for element to be present │
│ [ ] Wait for element to be visible │
│ [ ] Wait for element to be interactive │
│ │
│ After navigation: │
│ [ ] Wait for URL to change │
│ [ ] Wait for key element to appear │
│ [ ] Check for error messages │
│ │
│ On failure: │
│ [ ] Take screenshot │
│ [ ] Capture current URL │
│ [ ] Report what was expected vs found │
│ │
└─────────────────────────────────────────────────────────────────────────┘
7.3 What Evidence to Capture?
| Evidence | When | Purpose |
|---|---|---|
| Screenshot (before) | Start of test | Baseline |
| Screenshot (after action) | Form fill, click | Verification |
| Screenshot (failure) | On any error | Debugging |
| Console messages | Throughout | JS errors |
| Timing data | Each step | Performance |
8. Thinking Exercise
8.1 Map the Testing Workflow
Trace a login test through the skill:
1. User: "Test the login flow"
2. Skill discovers "web testing" intent
└── Matches description: "web testing", "login", "browser"
3. Read SKILL.md instructions
└── Follow the testing workflow
4. Testing Steps:
a. Navigate to login URL
└── Tool: mcp__claude-in-chrome__navigate
└── Wait: Page loads completely
b. Take screenshot (before)
└── Tool: mcp__claude-in-chrome__computer (screenshot)
c. Find username field
└── Tool: mcp__claude-in-chrome__find
└── Query: "username input" or "email field"
d. Enter username
└── Tool: mcp__claude-in-chrome__form_input
└── Use ref from find step
e. Find and enter password
└── Same pattern as username
f. Click submit
└── Tool: mcp__claude-in-chrome__computer (left_click)
└── On submit button location
g. Wait for navigation
└── Check URL changed
└── Or check for dashboard element
h. Verify success
└── Tool: mcp__claude-in-chrome__read_page
└── Look for welcome message
i. Take screenshot (after)
└── Final state evidence
5. Report results
└── PASSED/FAILED + timing + screenshots
Questions to consider:
- How do you handle login failures (wrong password)?
- What if the selector doesn’t match anything?
- How do you parameterize test data?
9. The Interview Questions They’ll Ask
- “How would you automate web testing with an AI assistant?”
- Expected: Use skills to orchestrate browser tools, combining AI reasoning with automation
- Bonus: Discuss advantages (natural language, adaptive) vs traditional frameworks
- “What makes browser automation tests flaky, and how do you prevent it?”
- Expected: Timing issues, dynamic content, poor selectors
- Bonus: Smart waits, stable selectors, retry logic
- “How do you handle authentication in automated tests?”
- Expected: Test accounts, masked credentials, don’t use production data
- Bonus: Session tokens, cookie injection, API-based login
- “What’s the difference between E2E testing and unit testing?”
- Expected: E2E tests full flows in real browser; unit tests isolated code
- Bonus: Testing pyramid, when to use each
- “How would you implement visual regression testing?”
- Expected: Screenshot comparison against baselines
- Bonus: Pixel diff tools, handling acceptable differences
10. Solution Architecture
10.1 Skill Component Diagram
┌─────────────────────────────────────────────────────────────────────────┐
│ WEB-TESTING SKILL ARCHITECTURE │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ SKILL.md │ │
│ │ ───────────────────────────────────────────────────────────── │ │
│ │ Orchestrator: coordinates testing workflow using MCP tools │ │
│ │ │ │
│ │ allowed-tools: │ │
│ │ - mcp__claude-in-chrome__navigate │ │
│ │ - mcp__claude-in-chrome__form_input │ │
│ │ - mcp__claude-in-chrome__computer │ │
│ │ - mcp__claude-in-chrome__read_page │ │
│ │ - mcp__claude-in-chrome__find │ │
│ │ - mcp__claude-in-chrome__tabs_context_mcp │ │
│ └───────────────────────────────┬──────────────────────────────────┘ │
│ │ │
│ ┌───────────────────┼───────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │
│ │ templates/ │ │ SELECTORS.md │ │ REFERENCES.md │ │
│ │ │ │ │ │ │ │
│ │ login_test.md │ │ Common form │ │ Best practices │ │
│ │ form_test.md │ │ selectors for │ │ for web testing │ │
│ │ search_test.md │ │ popular sites │ │ │ │
│ └─────────────────┘ └─────────────────┘ └─────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ CHROME MCP TOOLS │ │
│ │ │ │
│ │ navigate form_input computer read_page find │ │
│ │ │ │ │ │ │ │ │
│ │ ▼ ▼ ▼ ▼ ▼ │ │
│ │ ┌──────────────────────────────────────────────────────────┐ │ │
│ │ │ CHROME BROWSER │ │ │
│ │ └──────────────────────────────────────────────────────────┘ │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
10.2 Test Execution Flow
┌─────────────────────────────────────────────────────────────────────────┐
│ TEST EXECUTION FLOW │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ │
│ │ 1. SETUP │ │
│ │ Get tab ID │ mcp__claude-in-chrome__tabs_context_mcp │
│ │ Navigate │ mcp__claude-in-chrome__navigate │
│ │ Screenshot │ mcp__claude-in-chrome__computer (screenshot) │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ 2. INTERACT │ │
│ │ Find element │ mcp__claude-in-chrome__find │
│ │ Fill form │ mcp__claude-in-chrome__form_input │
│ │ Click button │ mcp__claude-in-chrome__computer (left_click) │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ 3. WAIT │ │
│ │ URL change │ Check new URL != old URL │
│ │ Element │ mcp__claude-in-chrome__read_page │
│ │ appears │ Look for success indicator │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ 4. VERIFY │ │
│ │ Check text │ mcp__claude-in-chrome__get_page_text │
│ │ Check URL │ Compare to expected │
│ │ Check element│ mcp__claude-in-chrome__read_page │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ 5. EVIDENCE │ │
│ │ Screenshot │ mcp__claude-in-chrome__computer (screenshot) │
│ │ Log results │ Report PASSED/FAILED │
│ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
11. Implementation Guide
11.1 Phase 1: Create Skill Structure
# Create skill directory
mkdir -p ~/.claude/skills/web-testing/templates
# Create files
touch ~/.claude/skills/web-testing/SKILL.md
touch ~/.claude/skills/web-testing/SELECTORS.md
touch ~/.claude/skills/web-testing/templates/login_test.md
touch ~/.claude/skills/web-testing/templates/form_test.md
11.2 Phase 2: Write the SKILL.md
---
name: web-testing
description: Automate web browser testing including login flows, form submissions, and UI verification. Use this when the user wants to test web functionality, verify a website works, or check UI elements.
allowed-tools:
- mcp__claude-in-chrome__navigate
- mcp__claude-in-chrome__form_input
- mcp__claude-in-chrome__computer
- mcp__claude-in-chrome__read_page
- mcp__claude-in-chrome__find
- mcp__claude-in-chrome__tabs_context_mcp
- mcp__claude-in-chrome__get_page_text
---
# Web Testing Assistant
Automate browser testing with reliable patterns.
## Testing Workflow
### 1. Setup
Before any test:
1. Get current tab context using `tabs_context_mcp`
2. If no tabs exist, create one with `tabs_create_mcp`
3. Store the tab ID for all subsequent operations
### 2. Navigate
1. Use `navigate` tool to go to the target URL
2. Take a screenshot immediately after navigation
3. Check for any error pages (404, 500, etc.)
### 3. Interact
For each interaction:
1. Use `find` to locate elements by natural language description
2. Verify element was found before interacting
3. For form fields: use `form_input` with the element ref
4. For clicks: use `computer` with `left_click` action
5. Take screenshots after significant actions
### 4. Wait After Actions
After form submissions or navigation triggers:
1. Check if URL changed (compare before/after)
2. Look for success/error indicators using `read_page`
3. Use `computer` with `wait` action if needed (max 5 seconds)
4. Check for loading indicators disappearing
### 5. Verify Outcomes
Verification strategies:
1. URL verification: Check current URL matches expected
2. Text verification: Use `get_page_text` to find success messages
3. Element verification: Use `read_page` to find expected elements
4. Negative verification: Ensure error messages are NOT present
### 6. Report Results
After test completion, provide:
- Overall status: PASSED or FAILED
- List of steps completed with timing
- Any failures with details
- Screenshots captured
## Common Selectors
### Login Forms
- Username: `input[name="username"]`, `input[type="email"]`, `#email`
- Password: `input[type="password"]`
- Submit: `button[type="submit"]`, `input[type="submit"]`
### Forms
- Text inputs: `input[name="fieldname"]`
- Selects: `select[name="fieldname"]`
- Checkboxes: `input[type="checkbox"]`
- Submit buttons: `button[type="submit"]`
### Navigation
- Links: `a[href*="path"]`
- Buttons: `button`, `.btn`
- Menu items: `nav a`, `.menu-item`
## Error Handling
If an action fails:
1. Take a screenshot of current state
2. Report what was expected vs what happened
3. Check for error messages on the page
4. Suggest possible causes
## Security Notes
- Never log actual password values
- Mask sensitive data in output
- Don't store credentials in test files
- Use test accounts, not production
11.3 Phase 3: Create Test Templates
templates/login_test.md:
# Login Test Template
## Test: Login Flow
### Inputs Required
- URL: Login page URL
- Username: Test username/email
- Password: Test password (will be masked in output)
### Steps
1. **Navigate to Login**
- Go to {url}
- Screenshot: "login_page"
- Verify: Login form is present
2. **Fill Credentials**
- Find username field
- Enter: {username}
- Find password field
- Enter: {password} (mask in output)
3. **Submit**
- Find submit button
- Click submit
- Wait for navigation
4. **Verify Success**
- Check URL changed from login page
- Look for dashboard/home indicators
- Screenshot: "after_login"
### Success Criteria
- [ ] No error messages present
- [ ] URL changed to authenticated page
- [ ] User identifier visible (name, avatar)
### Failure Indicators
- Error message like "Invalid credentials"
- URL still on login page
- Login form still visible
11.4 Phase 4: Create Selectors Reference
SELECTORS.md:
# Common Web Selectors
## By Attribute Type
### Test IDs (Most Reliable)
[data-testid=”login-button”] [data-cy=”submit-form”] [data-test=”username-input”]
### Form Fields
input[name=”email”] input[type=”password”] select[name=”country”] textarea[name=”message”]
### Buttons
button[type=”submit”] button:contains(“Sign In”) .btn-primary
## By Site Type
### Generic Login
- Username: `input[name="username"], input[type="email"], #email, #username`
- Password: `input[type="password"], #password`
- Submit: `button[type="submit"], input[type="submit"], .login-button`
### Search
- Input: `input[type="search"], input[name="q"], input[name="query"]`
- Button: `button[type="submit"], .search-button`
### Navigation
- Main nav: `nav a, .nav-link, .menu-item`
- Logo/Home: `a.logo, a[href="/"], .brand`
12. Hints in Layers
Hint 1: Start with Navigation
First, just get Claude to navigate and take a screenshot:
1. Use tabs_context_mcp to get tab ID
2. Use navigate to go to URL
3. Use computer with action: "screenshot"
Verify Chrome MCP is working before adding more complexity.
Hint 2: Add Form Filling
Use find to locate elements, then form_input with the ref:
1. find: query="username input field"
→ Returns ref like "ref_1"
2. form_input: ref="ref_1", value="test@example.com"
Hint 3: Handle Waits
After clicking submit, verify the action completed:
1. Click submit button
2. Use computer with action: "wait", duration: 2
3. Read page and check for success element
4. Or check URL changed from login to dashboard
Hint 4: Create Test Templates
Add templates/ directory with patterns for common tests.
In SKILL.md, reference them: “For login tests, follow the pattern in templates/login_test.md”
13. Common Pitfalls & Debugging
13.1 Frequent Mistakes
| Pitfall | Symptom | Solution |
|---|---|---|
| No tab ID | “Must provide tab ID” errors | Always call tabs_context_mcp first |
| Element not found | Empty find results | Use more specific/natural queries |
| Timing issues | Actions fail intermittently | Add waits after navigation/clicks |
| Wrong selector | Clicking wrong element | Use find tool with natural language |
| Password in logs | Credentials visible | Mask sensitive values in output |
13.2 Debugging Steps
- Take screenshots frequently: See exactly what Claude sees
- Check tab context: Is Claude using the right tab?
- Use read_page: See the accessibility tree
- Try find tool: Verify elements can be located
- Check console: Look for JavaScript errors
14. Extensions & Challenges
14.1 Beginner Extensions
- Add support for multi-step forms
- Handle “Remember me” checkboxes
- Verify specific text content
14.2 Intermediate Extensions
- Visual regression testing (compare screenshots)
- Network request verification
- Handle authentication cookies
- Test across multiple pages
14.3 Advanced Extensions
- Parallel test execution
- Test data parameterization
- Retry logic for flaky tests
- Integration with CI/CD
15. Books That Will Help
| Topic | Book/Resource | Chapter/Section |
|---|---|---|
| Web testing | “Testing Web APIs” by Winteringham | Chapters 3-5 |
| E2E patterns | “The Art of Software Testing” | Chapter 8 |
| DOM manipulation | MDN Web Docs | Selectors guide |
| Browser automation | Playwright/Puppeteer docs | Getting started |
16. Self-Assessment Checklist
Understanding
- I understand how skills invoke MCP tools
- I can explain wait strategies and why they matter
- I know what makes selectors reliable vs fragile
- I understand the testing pyramid
Implementation
- Browser navigation works reliably
- Forms are filled correctly
- Screenshots are captured at key moments
- Tests report clear results
Growth
- I can add new test patterns as templates
- I can debug failing tests using screenshots
- I understand when to use browser testing vs other approaches
17. Learning Milestones
| Milestone | Indicator |
|---|---|
| Browser navigation works | You understand Chrome MCP basics |
| Forms are filled correctly | You understand selectors and input |
| Tests handle timing | You’ve implemented wait strategies |
| Tests report results | You’ve created a complete workflow |
This guide was expanded from CLAUDE_CODE_MASTERY_40_PROJECTS.md. For the complete learning path, see the project index.