# Dogfood

> Dogfood: Systematic Web Application QA Testing

- Skill: `lucadominguez/dogfood` (Agent Skill)
- Install (CLI): `npx skillmds@latest add lucadominguez/dogfood`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lucadominguez/dogfood/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: lucadominguez (https://skillmd.com/u/lucadominguez)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lucadominguez/dogfood

---

# 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

- **Preferred:** Browser toolset available (`browser_navigate`, `browser_snapshot`, `browser_click`, `browser_type`, `browser_vision`, `browser_console`, `browser_scroll`, `browser_back`, `browser_press`)
- **Fallback:** If browser tools are unavailable, use Phase 2B (curl + source-code reverse-engineering) — see "Fallback: No Browser Available" below
- A target URL and testing scope from the user

## Inputs

The user provides:
1. **Target URL** — the entry point for testing
2. **Scope** — what areas/features to focus on (or "full site" for comprehensive testing)
3. **Output directory** (optional) — where to save screenshots and the report (default: `./dogfood-output`)

## Workflow

Follow this 5-phase systematic workflow (use Phase 2B instead of Phase 2 when browser tools are unavailable).

### Phase 0: Tool Availability Check

Before starting, check which tools are available in your toolset. If `browser_navigate` is absent, skip directly to Phase 2B (static analysis via curl + source inspection) instead of Phase 2 (browser interaction). You can still deliver a thorough review — often 80%+ of findings are discoverable from source code alone, especially for SPAs built on frameworks like React, TanStack Start, or Next.js.

### Phase 1: Plan

1. Create the output directory structure:
   ```
   {output_dir}/
   ├── screenshots/       # Evidence screenshots
   └── report.md          # Final report (generated in Phase 5)
   ```
2. Identify the testing scope based on user input.
3. 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:

1. **Navigate** to the page:
   ```
   browser_navigate(url="https://example.com/page")
   ```

2. **Take a snapshot** to understand the DOM structure:
   ```
   browser_snapshot()
   ```

3. **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.

4. **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.

5. **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

6. **After each interaction**, check for:
   - Console errors: `browser_console()`
   - Visual changes: `browser_vision(question="What changed after the interaction?")`
   - Expected vs actual behavior

### Phase 2B: Static Analysis (No Browser Available)

When browser tools are unavailable, use curl + source-code reverse-engineering to extract app structure, features, and issues. This works especially well for SPAs built on React/TanStack Start/Next.js where the SSR HTML and JS bundles contain rich information.

**Step 1: Discover all routes**
```bash
# Fetch the landing page and extract linked pages
curl -sL https://example.com/ | grep -oP 'href="([^"]+)"' | sort -u

# Probe common SPA routes
for path in / /login /signup /app /settings /privacy /onboarding; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://example.com${path}")
  echo "$path -> $code"
done
```

**Step 2: Download and extract SSR content from each page**
```bash
curl -sL -o /tmp/page.html https://example.com/page

# Extract the React SSR content (varies by framework)
# TanStack Start: <!--$--> ... <!--/$-->
# Next.js: <div id="__next"> ... </div>
python3 -c "
import re
with open('/tmp/page.html', 'r') as f:
    content = f.read()
body = re.search(r'<!--\\\$-->(.*?)<!--/\\\$-->', content, re.DOTALL)
if body:
    text = re.sub(r'<[^>]+>', ' ', body.group(1))
    text = re.sub(r'\s+', ' ', text).strip()
    print(text)
"
```

**Step 3: Download JS bundles to infer features**
```bash
# Extract all JS bundle references from the HTML
grep -oP '/assets/[^"]+\.js' /tmp/page.html | sort -u | while read bundle; do
  curl -sL -o "/tmp/$(basename $bundle)" "https://example.com$bundle"
done

# Extract readable strings from minified bundles
python3 -c "
import re
with open('/tmp/app-bundle.js', 'r') as f:
    content = f.read()
# Key UI strings, feature flags, API endpoints
strings = re.findall(r'\"([A-Za-z][A-Za-z0-9 .,!?'\-:;()@#\$%&*+/<>=]{8,})\"', content)
for s in sorted(set(strings)):
    print(s)
"
```

**Step 4: Identify framework and architecture**
- Check for framework fingerprints: `__NEXT_DATA__` (Next.js), TanStack Router stream barriers (`$R["tsr"]`), `__REACT_DEVTOOLS_GLOBAL_HOOK__`
- Identify server functions: look for hashed handler IDs in `createServerFn` calls (TanStack Start) or `"use server"` directives (Next.js)
- Extract icon names from Lucide: `k("icon-name")` pattern
- Extract CSS custom properties and gradients to assess visual design quality

**Step 5: Probe API endpoints**
```bash
for path in /api/ /api/auth /api/users /api/search /_rsc /api/health; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://example.com${path}")
  echo "$path -> $code"
done
```

Note: TanStack Start server functions use hashed RPC calls, not REST endpoints. A 404 on `/api/*` doesn't mean no backend — look for `createServerFn` and `useServerFn` in the JS bundles.

**Step 6: Test interactive endpoints**
```bash
# Try POSTing to common endpoints
curl -s -X POST 'https://example.com/api/signup' \
  -H 'Content-Type: application/json' \
  -d '{"email":"test@test.com","password":"test1234"}' \
  -w "\nHTTP: %{http_code}"
```

**Step 7: Check meta tags and SEO**
```bash
curl -s https://example.com | grep -oP '<meta[^>]+>' | head -20
```
Look for wrong OG titles (e.g. "Lovable App" instead of actual app name), missing descriptions, broken image URLs.

### Phase 3: Collect Evidence

For every issue found:

1. **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.

2. **Record the details**:
   - URL where the issue occurs
   - Steps to reproduce
   - Expected behavior
   - Actual behavior
   - Console errors (if any)
   - Screenshot path

3. **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

1. Review all collected issues.
2. De-duplicate — merge issues that are the same bug manifesting in different places.
3. Assign final severity and category to each issue.
4. Sort by severity (Critical first, then High, Medium, Low).
5. 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:
1. **Executive summary** with total issue count, breakdown by severity, and testing scope
2. **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
3. **Summary table** of all issues
4. **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.
- **For viral/consumer apps** (anonymous compliment apps, social networks, teen-focused products), load `references/gas-app-benchmark.md` for the Gas app competitive benchmark — it covers the school-network growth engine, poll mechanics, hints system, and monetization patterns that made Gas a $100M acquisition.
- **To turn QA findings into improved variants**, load the `design-generation` skill — it covers multi-branch generation with design philosophies, automated feature extraction, scoring, and iterative critic+builder refinement to produce higher-quality alternatives to the pages you just audited.

## Reference Files

- `references/issue-taxonomy.md` — Severity and category classification system
- `references/gas-app-benchmark.md` — Gas app viral growth mechanics and competitive benchmark for anonymous/social/teen apps
- `references/spa-reverse-engineering.md` — **Load when browser tools are unavailable.** Full 6-phase SPA reverse-engineering workflow: route discovery, SSR extraction, JS bundle analysis, CSS design system reconstruction, API probing, and mock/real feature assessment. Covers TanStack Start, Next.js, and React SPAs specifically.
- `references/api-qa-testing.md` — **Load when testing desktop/server apps via debug HTTP API.** WSL→Windows bridge pattern, structured API QA methodology (pre-flight → suites → diagnostics → gauntlet), pass/fail report template, Electron process management, and common pitfalls (false positives, store-vs-engine persistence, dedup bugs, elevation modes).
- `references/pixel-analysis.md` — **Load when evaluating UI screenshots without vision tools.** PIL-based pixel sampling to reconstruct layout zones, color schemes, content density, and contrast problems from screenshot files. Use when screenshots are on disk but `vision_analyze` or `browser_vision` are unavailable.