Dogfood: Structured Exploratory QA Testing for Web Applications

Purpose

Dogfood provides a systematic process for conducting exploratory quality assurance (QA) testing on web applications using browser tools. It guides you through capturing issues, collecting evidence, and producing a structured bug report. This approach ensures repeatability and thoroughness during manual testing.

When to Use

• When performing manual QA testing of a web application.
• When you need a structured, repeatable process for exploratory testing.
• When documenting bugs with evidence such as screenshots and console logs.

Capabilities

• Navigate to web pages.
• Take DOM snapshots and annotated screenshots.
• Click, type, scroll, press keys, and go back in the browser.
• Check the JavaScript console for errors.
• Capture evidence (screenshots) of issues.
• Classify issues by severity and category.
• Generate a structured bug report with an executive summary, per-issue details, and a summary table.

Prerequisites

• The browser toolset must be available. This includes the following functions: browser_navigate, browser_snapshot, browser_click, browser_type, browser_vision, browser_console, browser_scroll, browser_back, browser_press.
• The user must provide a target URL and a testing scope.

Parameters

Parameter	Meaning	Required
Target URL	Entry point URL for testing.	true
Scope	Areas or features to focus on, or full site for comprehensive testing.	true
Output directory	Where to save screenshots and report. Defaults to ./dogfood-output.	false

Procedures

The testing process follows five phases: Plan, Explore, Collect Evidence, Categorize, and Report.

Phase 1: Plan

1. Create the output directory structure. The default location is ./dogfood-output, but you can specify a custom path using the Output directory parameter. The structure must be:

{output_dir}/
├── screenshots/       # Evidence screenshots
└── report.md          # Final report (generated in Phase 5)

2. Identify the testing scope from user input. This can be specific areas or features, or full site for comprehensive testing.
3. Build a rough sitemap covering:
   • Landing page.
   • Navigation links.
   • Key user flows.
   • Forms and interactive elements.
   • Edge cases (empty states, error pages, 404s).

Phase 2: Explore

Execute the following steps systematically for each page or component:

1. Navigate to the page using:

browser_navigate(url="https://example.com/page")

2. Take a DOM snapshot:

browser_snapshot()

3. Check the JavaScript console for errors. This must be done after every navigation and every significant interaction:

browser_console(clear=true)

4. Take an annotated screenshot to understand the page layout and identify issues:

browser_vision(question="Describe the page layout, identify any visual issues, broken elements, or accessibility concerns", annotate=true)

Using annotate=true overlays numbered [N] labels on interactive elements, mapping to references like @eN.

5. Test interactive elements systematically:

   • Click buttons and links using browser_click(ref="@eN").
   • Fill forms using browser_type(ref="@eN", text="test input").
   • Test keyboard navigation with browser_press(key="Tab") and browser_press(key="Enter").
   • Scroll through pages using browser_scroll(direction="down").
   • Test form validation with invalid inputs and empty submissions.

6. After each interaction:

   • Check for console errors using browser_console().
   • Check visual changes using browser_vision(question="What changed after the interaction?").
   • Compare expected versus actual behavior.

Phase 3: Collect Evidence

For each 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.

2. Record the following details:

   • URL where the issue occurred.
   • Steps to reproduce.
   • Expected behavior.
   • Actual behavior.
   • Console errors (if any).
   • Screenshot path.

3. Classify the issue using the taxonomy defined in 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 the same bug that manifests 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

1. Generate the final report using the template at templates/dogfood-report-template.md.
2. Include the following sections:
   • Executive summary: total issue count, breakdown by severity, testing scope.
   • Per-issue sections: issue number and title, severity and category badges, URL, description, steps to reproduce, expected vs. actual behavior, screenshot references (use MEDIA: for inline images), console errors if relevant.
   • Summary table of all issues.
   • Testing notes: what was tested, what was not, any blockers.
3. Save the report to {output_dir}/report.md.

Constraints and Caveats

• The browser toolset must be available: browser_navigate, browser_snapshot, browser_click, browser_type, browser_vision, browser_console, browser_scroll, browser_back, browser_press.
• The user must provide a target URL and testing scope.
• The output directory defaults to ./dogfood-output if not specified.
• You must check browser_console() after every navigation and every significant interaction. Silent JavaScript errors are high-value findings.
• Use annotate=true with browser_vision when you need to reason about interactive element positions or when snapshot references are unclear.
• Test with both valid and invalid inputs.
• Scroll through long pages to check below-the-fold content.
• Test navigation flows end-to-end.
• Check responsive behavior via screenshots.
• Test edge cases: empty states, very long text, special characters, rapid clicking.
• Include MEDIA: in the report for inline screenshot images.

Failure Modes

• Missing console errors if browser_console() is not called after interactions.
• Incomplete evidence if screenshots are not taken for each issue.
• De-duplication errors if the same bug is not merged.
• Report missing required sections (executive summary, per-issue details, summary table, testing notes).
• Screenshots not saved or referenced correctly in the report.

Example Workflow

1. Navigate to a page using browser_navigate.
2. Take a DOM snapshot with browser_snapshot.
3. Check the console with browser_console(clear=true).
4. Take an annotated screenshot with browser_vision using annotate=true.
5. Click a button using browser_click(ref="@eN").
6. Check the console again with browser_console().
7. Capture a screenshot of the resulting issue using browser_vision with annotate=false.
8. Record the details, classify the issue, and include it in the final report.