exploratory-testing

Exploratory testing (exploratory-testing)

When requirements are incomplete, the system is unfamiliar, and documentation is insufficientIndependentExploratory testing session: charter-driven, designing while exploring, producing system understanding and a risk list rather than executing existing test cases.

• Input: entry point of the system under test (environment + accounts), exploration topic or charter, (optional) existing requirements materials
• Output (written to disk)：{项目}/探索笔记_{主题}.md(charter, system understanding, risk list, test ideas, discovered bugs) — in the bypass scenario, serves as input for requirement-analysis input for
• Applicable: new systems, legacy systems, missing documentation, black-box testing, Agent autonomous testing

When to Use

• Newly taken over/unfamiliar system, documentation missing or untrustworthy; explore first, then model
• Requirements are incomplete; exploration is needed to fill in system understanding and the risk list
• Autonomous testing in a black-box environment (only entry point and accounts)

When NOT to Use

• To write automationreconnaissance(understand page structure, extract selectors, write Page Objects) → automated-e2e-testing Workflow Zero (business familiarization)
• Execute according to existing test cases → automated-e2e-testing（UI）/ api-testing(API)
• Root cause analysis of confirmed bugs → bug-analysis
• end-to-end pipeline → qa(this skill is its bypass stage 0)

Exploration notes schema (output structure)

# 探索笔记：{主题}

## Charter（本轮探索的使命）
- 目标：{回答什么问题 / 覆盖什么区域}
- 范围：{系统/模块/流程}
- 时长/停点：{时间盒或停止条件}

## 系统理解（探索中修正）
- 入口与导航路径 / 角色与权限 / 核心流程 / 数据流向 / 状态与流转

## 风险清单（每条带证据标注，此时加载 `../core/evidence.md`）
- R?：{风险描述}｜level: {Critical/High/Medium/Low，按 `../core/risk-model.md` 的 Impact × Likelihood 预评}｜evidence: {E0–E4 + 来源}｜confidence: {high/medium/low}｜status: {fact / inference / risk / hypothesis}
  （R? 为会话内临时编号；移交 `test-strategy` 时并入其 Risk Map 统一重编为 R1…，探索笔记原文编号不保留）

## 测试想法（后续转化为正式用例的候选）
- 想法 → 建议归属：{test-case-writing 直接产出 / 需先澄清的问题}

## 发现的 Bug（现象 + 复现步骤 + 证据；未定性，标 Hypothesis）

## 未解之谜（需要用户/开发澄清的问题）

Workflow

1. Formulate a charter (define the mission first, then act)

• Three elements of a charter:Goal(what questions to answer, e.g. "what are the prerequisites for coupon claiming"),Scope(which system/process),Stop point(time box or "risk list reaches 10 items")
• When the topic is unknown, align with the user in one sentence: "What do you want to find out in this round of exploration?"
• No environment/accounts → request them first (entry URL, accounts for each role, data description),do not start exploration without credentials

2. System reconnaissance (build an initial map)

• Log in → enumerate entry points and navigation paths → record the functional surface visible to each role
• Walk through the discoverable main flows and record: pages/APIs, data objects, states and transitions
• Use the browser automation capabilities available in the host (navigation, screenshots, API monitoring/capturing) to collect evidence, with this skill's note structure as the output —session and output belong to this skill, do not load other execution skills' instructions for this; when the host/environment has no browser automation capability, degrade tomanual exploration(test engineers operate according to manual steps + manually screenshot/transcribe responses), the note structure and evidence annotation remain unchanged, only evidence collection efficiency decreases

3. Exploration loop (design, execute, and record simultaneously)

Loop according to the charter goal:hypothesis → trigger → observe → record：

Exploration heuristics	Questions to ask
Input extremes	Empty values/oversized/special characters/negative numbers: how does the system block them
State traversal	Step-skipping operations (directly trigger subsequent steps without meeting prerequisites), reverse operations, repeated operations
Concurrency and race conditions	Two sessions operating on the same object simultaneously
Data lifecycle	Create → modify → delete → query again, is there any residue; what about cascading objects
Permission boundaries	Replay the same operation after switching roles/logging out (including calling the API directly)
Error recovery	State after retry following failure, reconnection after network loss, and timeout
Platform and environment	Switching browsers/resolutions/weak network/system configuration switches, is the behavior still consistent
Time and clock	Midnight/cross-day boundaries, expiration and scheduled task trigger timing, are the state and copy correct

• Record an evidence level for each observation (E3 runtime evidence takes priority—screenshots/raw response text); record inferences as Inference/Hypothesis, do not disguise them as facts
• When an anomaly is found, characterize it first, then record it: "Is this expected behavior or a Bug?" If uncertain → record it as an unsolved mystery and ask the user, do not judge it yourself (question format and adjudication write-up uniformly follow ../core/clarify-pattern.md, and use "Bug characterization" for the scenario)

4. Convergence and write-up

• Timebox reached / stop condition met → organize exploration notes and write them to disk 探索笔记_{主题}.md
• Knowledge capture determination: If the business rules, environment quirks, and flaky-noise criteria confirmed during exploration pass qa-memory 's write criteria (retesting in a new session can save one rediscovery), capture them into the project according to its process .qa/ knowledge base
• Risk list according to ../core/risk-model.md pre-rating (Impact × Likelihood; when evidence is insufficient, record status as risk/inference and note the reinforcement direction; do not use markers outside the status enum)
• Test idea classification: those that can be directly converted into test cases / those that need clarification first / those that need a dedicated environment

5. Delivery and handoff

• Bypass scenario (qa pipeline / before requirements modeling): hand the note path to requirement-analysis as modeling input
• Standalone scenario: deliver notes + a one-sentence conclusion to the user (degree of system understanding / highest risk / recommended next step)
• Bug handoff: confirmed → bug-analysis; test ideas converted to formal test cases → test-case-writing

Common Mistakes

Error	Consequence	Correct approach
Wandering without a charter	Exploration is unfocused and outputs are fragmented	Define the goal/scope/stop point first
Treating exploration as reconnaissance (only collecting selectors)	Zero responsibility confusion with the e2e workflow	The output is system understanding + a risk list, not a Page Object
Observations without evidence	Notes cannot be reviewed, and the risk list becomes invalid	Each observation carries an evidence level and source
Self-judging an anomaly as a Bug	False positive (it may be expected design)	If not characterized, record Hypothesis and ask the user
Writing all exploration findings directly as formal test cases on the spot	The session loses focus and the timebox gets out of control	Record test ideas and convert them uniformly after the session
Notes stay in the session and are not written to disk	Downstream cannot consume them, and the breakpoint is lost	Write to disk 探索笔记_{主题}.md