Dogfood: Systematic Web Application QA Testing
Overview
This skill guides you through systematic exploratory QA testing of web applications using the browser toolset. You will navigate the application, interact with elements, capture evidence of issues, and produce a structured bug report.
Prerequisites
- Browser toolset must be available (
browser_navigate, browser_snapshot, browser_click, browser_type, browser_vision, browser_console, browser_scroll, browser_back, browser_press)
- A target URL and testing scope from the user
Inputs
The user provides:
- Target URL — the entry point for testing
- Scope — what areas/features to focus on (or "full site" for comprehensive testing)
- Output directory (optional) — where to save screenshots and the report (default:
./dogfood-output)
Workflow
Follow this 5-phase systematic workflow:
Phase 1: Plan
- Create the output directory structure:
{output_dir}/
├── screenshots/ # Evidence screenshots
└── report.md # Final report (generated in Phase 5)
- Identify the testing scope based on user input.
- Build a rough sitemap by planning which pages and features to test:
- Landing/home page
- Navigation links (header, footer, sidebar)
- Key user flows (sign up, login, search, checkout, etc.)
- Forms and interactive elements
- Edge cases (empty states, error pages, 404s)
Phase 2: Explore
For each page or feature in your plan:
Navigate to the page:
browser_navigate(url="https://example.com/page")
Take a snapshot to understand the DOM structure:
browser_snapshot()
Check the console for JavaScript errors:
browser_console(clear=true)
Do this after every navigation and after every significant interaction. Silent JS errors are high-value findings.
Take an annotated screenshot to visually assess the page and identify interactive elements:
browser_vision(question="Describe the page layout, identify any visual issues, broken elements, or accessibility concerns", annotate=true)
The annotate=true flag overlays numbered [N] labels on interactive elements. Each [N] maps to ref @eN for subsequent browser commands.
Test interactive elements systematically:
- Click buttons and links:
browser_click(ref="@eN")
- Fill forms:
browser_type(ref="@eN", text="test input")
- Test keyboard navigation:
browser_press(key="Tab"), browser_press(key="Enter")
- Scroll through content:
browser_scroll(direction="down")
- Test form validation with invalid inputs
- Test empty submissions
After each interaction, check for:
- Console errors:
browser_console()
- Visual changes:
browser_vision(question="What changed after the interaction?")
- Expected vs actual behavior
Phase 3: Collect Evidence
For every issue found:
Take a screenshot showing the issue:
browser_vision(question="Capture and describe the issue visible on this page", annotate=false)
Save the screenshot_path from the response — you will reference it in the report.
Record the details:
- URL where the issue occurs
- Steps to reproduce
- Expected behavior
- Actual behavior
- Console errors (if any)
- Screenshot path
Classify the issue using the issue taxonomy (see references/issue-taxonomy.md):
- Severity: Critical / High / Medium / Low
- Category: Functional / Visual / Accessibility / Console / UX / Content
Phase 4: Categorize
- Review all collected issues.
- De-duplicate — merge issues that are the same bug manifesting in different places.
- Assign final severity and category to each issue.
- Sort by severity (Critical first, then High, Medium, Low).
- Count issues by severity and category for the executive summary.
Phase 5: Report
Generate the final report using the template at templates/dogfood-report-template.md.
The report must include:
- Executive summary with total issue count, breakdown by severity, and testing scope
- Per-issue sections with:
- Issue number and title
- Severity and category badges
- URL where observed
- Description of the issue
- Steps to reproduce
- Expected vs actual behavior
- Screenshot references (use
MEDIA:<screenshot_path> for inline images)
- Console errors if relevant
- Summary table of all issues
- Testing notes — what was tested, what was not, any blockers
Save the report to {output_dir}/report.md.
Tools Reference
| Tool |
Purpose |
browser_navigate |
Go to a URL |
browser_snapshot |
Get DOM text snapshot (accessibility tree) |
browser_click |
Click an element by ref (@eN) or text |
browser_type |
Type into an input field |
browser_scroll |
Scroll up/down on the page |
browser_back |
Go back in browser history |
browser_press |
Press a keyboard key |
browser_vision |
Screenshot + AI analysis; use annotate=true for element labels |
browser_console |
Get JS console output and errors |
Tips
- Always check
browser_console() after navigating and after significant interactions. Silent JS errors are among the most valuable findings.
- Use
annotate=true with browser_vision when you need to reason about interactive element positions or when the snapshot refs are unclear.
- Test with both valid and invalid inputs — form validation bugs are common.
- Scroll through long pages — content below the fold may have rendering issues.
- Test navigation flows — click through multi-step processes end-to-end.
- Check responsive behavior by noting any layout issues visible in screenshots.
- Don't forget edge cases: empty states, very long text, special characters, rapid clicking.
- When reporting screenshots to the user, include
MEDIA:<screenshot_path> so they can see the evidence inline.
1---2name: argentos-dogfood3description: Systematic exploratory QA testing of web applications — find bugs, capture evidence, and generate structured reports4---56# Dogfood: Systematic Web Application QA Testing78## Overview910This skill guides you through systematic exploratory QA testing of web applications using the browser toolset. You will navigate the application, interact with elements, capture evidence of issues, and produce a structured bug report.1112## Prerequisites1314- Browser toolset must be available (`browser_navigate`, `browser_snapshot`, `browser_click`, `browser_type`, `browser_vision`, `browser_console`, `browser_scroll`, `browser_back`, `browser_press`)15- A target URL and testing scope from the user1617## Inputs1819The user provides:20211. **Target URL** — the entry point for testing222. **Scope** — what areas/features to focus on (or "full site" for comprehensive testing)233. **Output directory** (optional) — where to save screenshots and the report (default: `./dogfood-output`)2425## Workflow2627Follow this 5-phase systematic workflow:2829### Phase 1: Plan30311. Create the output directory structure:32 ```33 {output_dir}/34 ├── screenshots/ # Evidence screenshots35 └── report.md # Final report (generated in Phase 5)36 ```372. Identify the testing scope based on user input.383. Build a rough sitemap by planning which pages and features to test:39 - Landing/home page40 - Navigation links (header, footer, sidebar)41 - Key user flows (sign up, login, search, checkout, etc.)42 - Forms and interactive elements43 - Edge cases (empty states, error pages, 404s)4445### Phase 2: Explore4647For each page or feature in your plan:48491. **Navigate** to the page:5051 ```52 browser_navigate(url="https://example.com/page")53 ```54552. **Take a snapshot** to understand the DOM structure:5657 ```58 browser_snapshot()59 ```60613. **Check the console** for JavaScript errors:6263 ```64 browser_console(clear=true)65 ```6667 Do this after every navigation and after every significant interaction. Silent JS errors are high-value findings.68694. **Take an annotated screenshot** to visually assess the page and identify interactive elements:7071 ```72 browser_vision(question="Describe the page layout, identify any visual issues, broken elements, or accessibility concerns", annotate=true)73 ```7475 The `annotate=true` flag overlays numbered `[N]` labels on interactive elements. Each `[N]` maps to ref `@eN` for subsequent browser commands.76775. **Test interactive elements** systematically:78 - Click buttons and links: `browser_click(ref="@eN")`79 - Fill forms: `browser_type(ref="@eN", text="test input")`80 - Test keyboard navigation: `browser_press(key="Tab")`, `browser_press(key="Enter")`81 - Scroll through content: `browser_scroll(direction="down")`82 - Test form validation with invalid inputs83 - Test empty submissions84856. **After each interaction**, check for:86 - Console errors: `browser_console()`87 - Visual changes: `browser_vision(question="What changed after the interaction?")`88 - Expected vs actual behavior8990### Phase 3: Collect Evidence9192For every issue found:93941. **Take a screenshot** showing the issue:9596 ```97 browser_vision(question="Capture and describe the issue visible on this page", annotate=false)98 ```99100 Save the `screenshot_path` from the response — you will reference it in the report.1011022. **Record the details**:103 - URL where the issue occurs104 - Steps to reproduce105 - Expected behavior106 - Actual behavior107 - Console errors (if any)108 - Screenshot path1091103. **Classify the issue** using the issue taxonomy (see `references/issue-taxonomy.md`):111 - Severity: Critical / High / Medium / Low112 - Category: Functional / Visual / Accessibility / Console / UX / Content113114### Phase 4: Categorize1151161. Review all collected issues.1172. De-duplicate — merge issues that are the same bug manifesting in different places.1183. Assign final severity and category to each issue.1194. Sort by severity (Critical first, then High, Medium, Low).1205. Count issues by severity and category for the executive summary.121122### Phase 5: Report123124Generate the final report using the template at `templates/dogfood-report-template.md`.125126The report must include:1271281. **Executive summary** with total issue count, breakdown by severity, and testing scope1292. **Per-issue sections** with:130 - Issue number and title131 - Severity and category badges132 - URL where observed133 - Description of the issue134 - Steps to reproduce135 - Expected vs actual behavior136 - Screenshot references (use `MEDIA:<screenshot_path>` for inline images)137 - Console errors if relevant1383. **Summary table** of all issues1394. **Testing notes** — what was tested, what was not, any blockers140141Save the report to `{output_dir}/report.md`.142143## Tools Reference144145| Tool | Purpose |146| ------------------ | ---------------------------------------------------------------- |147| `browser_navigate` | Go to a URL |148| `browser_snapshot` | Get DOM text snapshot (accessibility tree) |149| `browser_click` | Click an element by ref (`@eN`) or text |150| `browser_type` | Type into an input field |151| `browser_scroll` | Scroll up/down on the page |152| `browser_back` | Go back in browser history |153| `browser_press` | Press a keyboard key |154| `browser_vision` | Screenshot + AI analysis; use `annotate=true` for element labels |155| `browser_console` | Get JS console output and errors |156157## Tips158159- **Always check `browser_console()` after navigating and after significant interactions.** Silent JS errors are among the most valuable findings.160- **Use `annotate=true` with `browser_vision`** when you need to reason about interactive element positions or when the snapshot refs are unclear.161- **Test with both valid and invalid inputs** — form validation bugs are common.162- **Scroll through long pages** — content below the fold may have rendering issues.163- **Test navigation flows** — click through multi-step processes end-to-end.164- **Check responsive behavior** by noting any layout issues visible in screenshots.165- **Don't forget edge cases**: empty states, very long text, special characters, rapid clicking.166- When reporting screenshots to the user, include `MEDIA:<screenshot_path>` so they can see the evidence inline.