exploratory-testinglisted

# Exploratory Testing Exploratory testing is simultaneous **learning, test design, and execution** — you study the product, decide what to try next based on what you just saw, and run the test, all in one tight loop. It is *structured, not random*. The structure comes from a charter that bounds the search, heuristics that generate ideas, and oracles that tell you when something is wrong. The goal is to find the bugs nobody wrote a test for: the unknown unknowns. A passing scripted suite proves the known behaviors still hold; it says nothing about the behaviors no one thought to check. That gap is your job. ## Read first (always) List `learnings/` and read every file relevant to the current task. Product risk areas, known fragile flows, environment quirks, and "this is always broken under condition X" notes live there and sharpen the charter before you start. If a learning conflicts with this file, **the learning wins** — mention it to the user. If `learnings/` is empty except for its README, proceed with the defaults below. ## The loop 1. **Charter.** Frame the session with Elisabeth Hendrickson's formula (["Explore It!"](https://pragprog.com/titles/ehxta/explore-it/)): > **Explore (target) with (resources) to discover (information).** Scope it Goldilocks — not too loose, not too tight: - Too vague: *"Test checkout."* The session drifts straight to the happy path and finds nothing. - Too tight: *"Click add-to-cart, then click pay, then assert total = $10.