Dogfood: Systematic Web App QA Testing with Hermes Agent

Dogfood is a bundled Hermes Agent skill for exploratory QA testing of web applications. It turns a browser-capable agent into a structured bug hunter: you give it a URL and a scope, and it walks through a five-phase workflow that ends with a categorized bug report and screenshots. This is for anyone who needs reproducible, evidence-backed QA without writing test scripts by hand.

What it does

Dogfood automates the manual QA cycle. It navigates your target site, takes DOM snapshots and annotated screenshots, checks the JavaScript console for errors after every action, and logs issues with reproduction steps. The output is a report.md file with an executive summary, per-issue details, severity and category badges, and inline screenshot references. The skill does not replace a human tester's judgment, but it handles the repetitive parts: clicking through flows, checking console output, and documenting what it finds.

Before you start

You need the Hermes Agent browser toolset installed and available. The skill calls these tools directly:

• browser_navigate
• browser_snapshot
• browser_click
• browser_type
• browser_vision
• browser_console
• browser_scroll
• browser_back
• browser_press

You also need a target URL and a testing scope from the user. The scope can be a specific feature area or "full site" for comprehensive testing. An output directory is optional; the default is ./dogfood-output.

Dogfood runs on Linux, macOS, and Windows.

Workflow

The skill follows five phases. Each phase builds on the previous one.

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:

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 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: 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: so they can see the evidence inline.

When not to use it

Dogfood is for exploratory testing, not for regression test suites or performance benchmarking. If you need to run the same checks on every build, you are better off with a dedicated test framework. The skill also assumes the target is a web application accessible from the agent's browser; it will not work on native mobile apps or desktop software.

Limits and gotchas

• The skill depends on the browser toolset being fully functional. If the agent cannot launch a browser or the browser does not support the required tools, Dogfood will fail.
• The quality of the report depends on the agent's ability to interpret visual and DOM information. Complex single-page applications with heavy JavaScript may produce misleading snapshots.
• The issue taxonomy file (references/issue-taxonomy.md) and report template (templates/dogfood-report-template.md) must exist in the expected paths. If they are missing, the skill will not complete Phase 5.
• The agent may miss issues that require domain knowledge or subjective judgment. Dogfood is a tool for systematic coverage, not a replacement for a human QA engineer.

What pairs with this

Dogfood lives under the Software Development category in the bundled skills. It complements other skills in that category, such as code review or documentation generation, by feeding bug reports back into the development loop. The source page does not list specific companion skills, but the output report is designed to be consumed by a human or by another agent that can triage issues.