Dogfood: Systematic Web Application QA Testing Overview This skill guides you through systematic exploratory QA testing of web applications with browser exec . You will navigate the application, interact with elements, capture evidence of issues, and produce a structured bug report. Prerequisites The browser toolset must be enabled ( browser exec ). browser exec runs Python with pre imported helpers ( new tab , goto url , wait for load , page info , js , fill input , click at xy , capture screenshot , cdp ); browser state persists across calls, Python variables do not. 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: 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 Batch each step's actions into one browser exec call. For each page or feature in your plan: 1. Navigate with a console hook installed. Register the hook on the tab before navigating so errors thrown during page load are captured too: Re register the hook at the start of any later call that navigates. Silent JS errors are high value findings. 2. Read the page structure — list visible interactive elements with their viewport centres (use cdp('Accessibility.getFullAXTree') and filter in Python when you need roles/names): 3. Visually assess the page: call capture screenshot() and inspect the attached image for layout issues, broken elements, or accessibility concerns. If your model cannot view images, pass the printed path to vision analyze . 4. Test interactive elements systematically: Click buttons and links: js("document.querySelector(' submit').click()") , or click at xy(x, y) with a centre from step 2 Fill forms: fill input('input[name=email]', 'test input') Test keyboard navigation: cdp('Input.dispatchKeyEvent', type='keyDown', key='Tab', code='Tab', windowsVirtualKeyCode=9) followed by the matching keyUp , then js('document.activeElement.outerHTML.slice(0, 200)') to see where focus landed; same pattern with key='Enter' , code='Enter' , windowsVirtualKeyCode=13 Scroll through content: js('window.scrollBy(0, 800)') Go back: js('history.back()') , then wait for load() Test form validation with invalid inputs Test empty submissions 5. After each interaction , in the same call, check for: Console errors: print(js('window. qa errors []')) Visual changes: capture screenshot() and compare with the previous one Expected vs actual behavior ( page info() , or js() reading the relevant element) Phase 3: Collect Evidence For every issue found: 1. Take a screenshot showing the issue: capture screenshot() prints the saved path. Copy it to {output dir}/screenshots/ under a descriptive name (e.g. issue 03 broken login.png ) — 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 All browser actions are browser exec calls; these are the helpers and idioms used above. Action browser exec idiom Go to a URL new tab(url) once (or new tab('about:blank') before registering the hook), then goto url(url) ; follow with wait for load() Page state page info() DOM / accessibility tree js(...) extraction, or cdp('Accessibility.getFullAXTree') filtered in Python Click js("document.querySelector(sel).click()") or click at xy(x, y) Type into an input fill input(selector, text) Scroll js('window.scrollBy(0, 800)') Go back js('history.back()') Press a key cdp('Input.dispatchKeyEvent', type='keyDown', key=..., code=..., windowsVirtualKeyCode=...) + keyUp Screenshot capture screenshot() (image attached to the result; text only models use vision analyze on the path) JS console errors hook via cdp('Page.addScriptToEvaluateOnNewDocument', source=HOOK) , read with js('window. qa errors []') Tips Always read window. qa errors after navigating and after significant interactions. Silent JS errors are among the most valuable findings. Batch each sub procedure into one browser exec call (navigate, wait, extract, act, check errors) — fewer round trips, and the hook stays in place. Take a capture screenshot() when you need to reason about element positions or when DOM extraction is ambiguous; click at xy takes the centres from the element listing. 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.