← ClaudeAtlas

explorelisted

Run a session based exploratory test against a running app, in a real browser or on a device, and keep the session sheet. Produces findings, questions and bug drafts. Use when asked to explore, poke at, or manually test something, when a design says a condition needs a human rather than a script, or when there is no requirement to test against yet.
eduramos21/qa-automation-framework · ★ 0 · Testing & QA · score 66
Install: claude install-skill eduramos21/qa-automation-framework
# Explore Input: `$ARGUMENTS`. A charter, an area, a ticket, or nothing, in which case propose three charters and let the user pick. Exploratory testing is not clicking around. It is a timeboxed search for information about a specific question, with a record of what was tried. The record is half the value: without it you cannot tell the difference between "we looked and it was fine" and "nobody looked". ## The charter One sentence, in this shape: ``` Explore <target> with <resources> to discover <information> ``` Example: *Explore the checkout flow with the browser back button and a second tab to discover whether an order can be placed twice or totals can go stale.* A charter is good when it can be wrong. "Explore checkout" cannot be wrong. "Discover whether the total can disagree with what gets charged" can. Timebox it. Sixty minutes is a normal session, ninety is the ceiling. Say the box up front and stop when it runs out, even mid thread. What you did not get to goes in the sheet. ## Steps **1. Read the setup.** `qa-context`. You need the base URL env var and the tracker so bugs go to the right place. **2. Get a browser.** Use the Playwright MCP tools for web. For mobile, use the Appium or WebdriverIO MCP if the project has one configured, otherwise drive the device the way the mobile profile's notes describe. Never guess at what the screen shows. Take the accessibility snapshot and read it. A finding based on what you assumed is on the page is not a finding.