Dogfood

作者 nousresearch25a71a744cb9MIT252K 個星標收錄於 2026年10月8日更新於 2026年10月8日儲存庫今天更新

Exploratory QA of web apps: find bugs, evidence, reports.

AI 產生的概覽

透過瀏覽器工具組對網頁應用程式進行系統化探索式 QA,產出附截圖的結構化缺陷報告。

功能
此技能引導代理依五個階段對網頁應用程式進行探索式 QA:規劃測試範圍與網站地圖;使用瀏覽器導覽、快照、點擊、輸入與 console 檢查來探索頁面;為每個問題蒐集證據;依嚴重程度與類別歸類並去除重複;最後撰寫報告。它會產生一個輸出目錄,內含截圖與根據內建報告範本撰寫的 report.md,包含逐條問題說明、彙總表與測試備註。問題依內建的問題分類法分級(Critical/High/Medium/Low;Functional/Visual/Accessibility/Console/UX/Content)。
適用情境
當你需要對網頁應用程式進行端對端缺陷測試,並希望取得有證據佐證的書面報告時使用。它適合使用者提供目標 URL 與測試範圍的探索式 QA 情境。它並非針對單元測試或程式碼層級除錯。
執行需求
需要瀏覽器工具組(browser_navigate、browser_snapshot、browser_click、browser_type、browser_vision、browser_console、browser_scroll、browser_back、browser_press),需要使用者提供目標 URL 與測試範圍,並需要連線至受測應用程式的網路存取。它不附帶指令碼,內含一份參考分類法與一份報告範本。輸出目錄為選用(預設 ./dogfood-output)。

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:

  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:

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 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

ToolPurpose
browser_navigateGo to a URL
browser_snapshotGet DOM text snapshot (accessibility tree)
browser_clickClick an element by ref (@eN) or text
browser_typeType into an input field
browser_scrollScroll up/down on the page
browser_backGo back in browser history
browser_pressPress a keyboard key
browser_visionScreenshot + AI analysis; use annotate=true for element labels
browser_consoleGet 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.

來源與署名

來源:nousresearch/hermes-agent位於skills/software-development/dogfood提交25a71a7

授權條款: MIT

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架