/exploratory-qa

Scope and intent

A controlled workflow specification

This page defines the behaviour, controls, evidence, and outputs required from the skill. It does not claim that a language model can enforce security or correctness by wording alone.

Use when

Appropriate use

Use when learning a new feature, searching for unknown risks, investigating behaviour beyond scripted cases, or evaluating usability and resilience.

Do not use when

Non-goals

Do not use as unstructured clicking, as a replacement for required scripted verification, or as permission to test destructive ideas in shared environments.

8: versioned workflow phases
4: explicit approval gates
5: defined result states
9: versioned output artifacts

Material changes to the source, environment, identity, approved actions, or expected behaviour invalidate dependent approvals and require revalidation.

Workflow

The 8 phases

Each phase has explicit inputs and outputs. Approval gates are hard stops bound to exact versions and hashes.

Phase 1: Session preflight Gate 1 · approve session boundary

Confirm environment, build identity, role, tenant, data boundaries, allowed tools, time box, and whether customer or production data is prohibited.

build · environment · charter owner · time box · role · data boundary

Phase 2: Charter definition

Write one focused mission describing the target, risks, users, and questions. Split broad missions into separate sessions.

explore target · with resources · to discover information

Phase 3: Heuristic and tour selection

Choose relevant tours such as feature, data, claims, interruption, configuration, platform, accessibility, consistency, recovery, and misuse.

selected heuristics · reason · excluded tours

Phase 4: Data and state preparation Gate 2 · approve actions

Create isolated data, capture starting state, define reversible actions, and record any stubs, clocks, flags, or network shaping.

starting state · resource IDs · side effects · cleanup

Phase 5: Exploration and note capture

Explore deliberately, branching from observations while recording timestamps, actions, questions, ideas, evidence references, and state transitions.

observations · questions · test ideas · coverage notes · interruptions

Phase 6: Finding reproduction and classification

Attempt to reproduce interesting behaviour, distinguish defects from usability concerns and questions, and preserve the original path when reproduction fails.

reproduction confidence · severity hypothesis · environment dependence

Phase 7: Debrief Gate 3 · confirm findings

Review what was covered, what remained untouched, strongest findings, unanswered questions, data created, and whether another charter is justified.

coverage map · findings · risks · follow-up charters

Phase 8: Publish session record and clean up Gate 4 · publish

Publish a concise session report, proposed defects, and follow-up work. Clean verified owned data and record residual state.

session notes · evidence bundle · defect proposals · cleanup report

Approval contract

Every gate approves an exact decision object

An approval cannot be reused after its environment, source, action plan, or approved document changes.

Approval gates and binding requirements
Gate	Decision	Required binding
1	Gate 1 · approve session boundary	Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state.
2	Gate 2 · approve actions	Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state.
3	Gate 3 · confirm findings	Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state.
4	Gate 4 · publish	Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state.

Result model

Defined states prevent vague conclusions

Attempt outcomes remain separate from these workflow results. Errors, cancellations, and invalid context are never silently converted into a pass.

NO MATERIAL FINDING

The session found no material issue within its explicit charter and coverage.

FINDINGS RECORDED

One or more reproducible defects, risks, usability concerns, or requirement questions were identified.

FOLLOW-UP REQUIRED

Promising leads or uncovered risk justify another targeted session.

BLOCKED

The session could not meaningfully explore the charter because of environment, access, or data limits.

ABORTED

The session ended early and the completed coverage is preserved.

Evidence contract

Evidence must directly support the claim

Evidence has provenance, capture context, privacy classification, retention, and integrity metadata. A convenient artifact is not automatically sufficient proof.

Required evidence by claim type
Claim	Primary evidence	Required validation
Session path	Timestamped notes or trace	Key branches and state transitions can be reconstructed.
Visual observation	Screenshot or video	Relevant context, build, role, and state are visible.
Intermittent behaviour	Attempt log and runtime evidence	Original event and later reproduction attempts are separated.
Usability concern	Observation plus user-goal impact	The concern describes friction, not personal preference alone.
Coverage	Charter map	Explored and unexplored areas are distinguished.
Data impact	Resource ledger	Created, changed, and remaining resources are identified.

Trust and safety

Controls that must be enforced outside the prompt

These controls belong in the runtime, connector permissions, sandbox, renderer, storage layer, and review process.

Runtime control

Time-box integrity

The session records pauses, interruptions, and actual exploration time.

Runtime control

Charter focus

Material detours become notes or new charters rather than silently replacing the mission.

Runtime control

Evidence honesty

Absence of a finding is never presented as comprehensive product coverage.

Runtime control

Safe experimentation

Destructive, privacy-sensitive, external, or production-like actions require explicit approval.

Runtime control

Original evidence retention

A non-reproducible observation keeps its first evidence and confidence level.

Runtime control

Debrief separation

Raw notes remain available; the polished report cannot erase uncertainty or skipped areas.

Decision policy

Ordered outcomes, not averaged pass counts

The first applicable high-severity outcome takes precedence. A manual override is recorded separately and never rewrites the calculated result.

BLOCKED

The charter could not be explored meaningfully.

FINDINGS RECORDED

Material findings require triage or action.

FOLLOW-UP REQUIRED

The session produced useful leads but insufficient coverage or certainty.

NO MATERIAL FINDING

No material issue was found within the stated charter and time box.

Known limitations

Uncertainty and coverage limits remain visible

The workflow documents what it cannot prove and what further evidence would change confidence.

Limit 1. Exploratory testing is sampling, not proof of absence.
Limit 2. Time boxes limit depth; uncovered areas must remain visible.
Limit 3. Usability observations may require user research or product validation.
Limit 4. Intermittent behaviour may remain unresolved after one session.
Limit 5. A broad feature often needs several narrow charters.
Limit 6. Shared environments can constrain aggressive recovery, load, or misuse exploration.

Outputs

Versioned records for review and continuation

Human summaries are generated from validated structured records. They are not maintained as separate, drifting sources of truth.

session-context.json