本文へ移動
cccskills
無料GitHub で公開

exploratory-testing

Plans and runs time-boxed exploratory testing when tester hours are scarce before a release - one tester with two free 45-minute blocks before code freeze, a high-stakes window such as year-end payroll, or a device and environment the scripted suite never touches. Session-based per the Bachs' SBTM: charters (Explore X with Y to discover Z), 60-90 minute sessions, session sheets with TBS metrics, and the PROOF debrief. Bundles the exploration heuristics as references - Whittaker's seven tours, Kelly's FCC CUTS VIDS, Bach's SFDPOT. Broader than exploratory-charter-author, which writes one charter document: this owns the whole cycle from budgeting the available hours to debriefing what was found. Use when deciding what to explore with the time available, and how to run and record those sessions.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qaスター 13(GitHub 13 + cccskills 0)
連携ツールOutlook

実行スコア 未検証

インストール方法を見る

含まれるファイル(31)

  • SKILL.md13.2 KB
  • .tessl-plugin/plugin.json938 B
  • evals/biometric-login-sixty-minutes/criteria.json4.9 KB
  • evals/biometric-login-sixty-minutes/task.md4.1 KB
  • evals/clinician-shift-swap-single-window/criteria.json5.2 KB
  • evals/clinician-shift-swap-single-window/task.md4.2 KB
  • evals/crm-import-handback-review/criteria.json4.8 KB
  • evals/crm-import-handback-review/task.md3.9 KB
  • evals/invoice-renderer-swap-regression/criteria.json4.8 KB
  • evals/invoice-renderer-swap-regression/task.md4.2 KB
  • evals/payroll-year-end-campaign/criteria.json4.6 KB
  • evals/payroll-year-end-campaign/task.md4.2 KB
  • evals/returns-portal-freeze-window/criteria.json5.3 KB
  • evals/returns-portal-freeze-window/task.md3.9 KB
  • evals/scanner-sync-unstable-environment/criteria.json4.8 KB
  • evals/scanner-sync-unstable-environment/task.md4.3 KB
  • evals/seatmap-flag-combination-blowout/criteria.json4.3 KB
  • evals/seatmap-flag-combination-blowout/task.md3.9 KB
  • evals/thermostat-schedule-clock-jumps/criteria.json4.5 KB
  • evals/thermostat-schedule-clock-jumps/task.md4.0 KB
  • evals/tv-app-new-tester-afternoon/criteria.json4.6 KB
  • evals/tv-app-new-tester-afternoon/task.md3.9 KB
  • references/charter-template.md5.3 KB
  • references/crusspic-stmpl.md9.2 KB
  • references/debrief.md10.6 KB
  • references/fcc-cuts-vids.md12.5 KB
  • references/hiccupps-f.md7.1 KB
  • references/session-review-checklist.md3.2 KB
  • references/session-sheet-and-metrics.md4.0 KB
  • references/sfdpot.md9.2 KB
  • references/tours.md12.3 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

exploratory-testing

Overview

Session-Based Test Management (SBTM) is the dominant framework for managing exploratory testing as a measurable, accountable activity. It was developed by Jonathan Bach + James Bach (1999-2000) and is documented at satisfice.com/sbtm.

The unit of work is a session - a time-boxed (60-90 min) chunk of focused exploratory testing against a mission stated as a charter. Sessions produce session sheets that capture what happened in a structured-enough format for management to aggregate, while leaving room for the tester to learn freely.

Exploratory testing is not "clicking around". ISTQB defines it as testing where "tests are simultaneously designed, executed, and evaluated while the tester learns about the test object" (ISTQB CTFL Syllabus v4.0.1 §4.4.2, p.44). Human-driven testing has two modes, and this skill owns one of them:

Scripted manual testingExploratory testing
DesignedBefore execution, by someone elseDuring execution, by the person running it
Fixed in advanceSteps, data, expected resultA mission and a time box only
OutputPass/fail per case, signed and datedSession notes, bugs, issues, new charters
FindsDeviations from what was anticipatedWhat nobody thought to anticipate

For the scripted side (step-tables, Gherkin, UAT scripts, checklists), use manual-test-script-author. This skill covers the exploratory side end to end: charter, session, heuristics, debrief, review.

When to use

  • Onboarding a tester to SBTM vocabulary.
  • Authoring a charter - what fields belong, what mission framing to use (references/charter-template.md).
  • Picking which tour, heuristic, or oracle to apply in a session (routing table below).
  • Reviewing a session sheet for completeness (references/session-review-checklist.md).
  • Building a session-tracking dashboard.

How to use

  1. Write the charter - "Explore <area> with <tools> to discover <information>". Keep it a mission, not a test-case list. Ready-to-fill card: references/charter-template.md.
  2. Time-box the session - 60-90 min, one charter, uninterrupted; ~2-hour hard cap before focus degrades.
  3. Test and record - explore per the charter (applying tours + heuristics from the routing table below) and log Areas, Bugs, and Issues in the session sheet as you go. Full template: references/session-sheet-and-metrics.md.
  4. Track TBS - note the Test / Bug / Setup split (plus Opportunity / Idle). Verify: T should land in the healthy 60-80% range before you trust the session; if T < 50%, stop and fix the cause (stabilise the environment or narrow the charter), then re-run the session before aggregating.
  5. Close with PROOF - debrief Past, Results, Outlook, Obstacles, Feelings with the lead within 24h (full template + worked example: references/debrief.md; lead-side review rules: references/session-review-checklist.md).
  6. Aggregate on the dashboard - roll sessions up weekly (throughput, avg T%, charter progress) to drive strategy, not a bugs-per-session KPI.

The unit: a session

Per Jonathan and James Bach's SBTM paper (satisfice.com):

"A session is an uninterrupted block of reviewable, chartered test effort... A session may be short (around 60 minutes) or long (up to about 2 hours). Two hours is generally considered the upper limit because tester focus degrades."

Properties of a session:

  • Time-boxed: 60-90 minutes typical; absolute upper bound ~2 hours
  • Chartered: has a stated mission (what to explore, what to learn)
  • Uninterrupted: no context-switching to other work mid-session
  • Reviewable: produces a session sheet that the lead can review

The charter

A charter states the mission for one session. Per Bach:

Explore <area>
With <tools / resources>
To discover <information>

Example: "Explore the cart promo-stacking flow with manual sample inputs to discover discount-application bugs." More charter examples are in references/session-sheet-and-metrics.md; a full charter-card template (mission + areas + oracles + dimensions + tours + deliverables) is in references/charter-template.md.

Charters are not test cases. They state what to investigate and leave the how to the tester's judgment in the session.

A backlog of charters drives multi-session campaigns. The lead prioritises charters per the test strategy (test-strategy-author) and the risk register (risk-matrix).

Choosing a heuristic or tour

Each reference is a distinct lens; a strong session composes 2-3, never all of them. Route by what the session needs:

You needLensReference
A themed bug-hunting mission on a product you already knowWhittaker's seven tours (Feature, Money, Landmark, Intellectual, Bad-data, Configuration, Garbage collector's)references/tours.md
Recon on an unfamiliar product, before any charter existsKelly's FCC CUTS VIDS eleven touring questionsreferences/fcc-cuts-vids.md
Ideas for what to vary when stuck mid-sessionBach's SFDPOT (Structure, Function, Data, Platform, Operations, Time)references/sfdpot.md
To decide whether an observation is a bugBolton's HICCUPPS-F oracle catalogreferences/hiccupps-f.md
Which quality criteria the session evaluatesBach's CRUSSPIC STMPL thirteen criteriareferences/crusspic-stmpl.md
A ready-to-fill charter cardCharter template + quality rulesreferences/charter-template.md
To close and file the sessionPROOF debrief template + aggregationreferences/debrief.md
To review someone else's completed session sheetLead's review checklist + verdict rulesreferences/session-review-checklist.md
The session-sheet template, TBS metrics, dashboardSBTM artifacts in fullreferences/session-sheet-and-metrics.md

The catalogs complement each other: tours give the session a theme, SFDPOT gives variations, HICCUPPS-F interprets observations, and CRUSSPIC STMPL frames the criteria. Bach + Bolton's Rapid Software Testing curriculum teaches them as one toolkit.

The session sheet and metrics

Each session produces a session sheet whose sections are: Charter, Areas, session timings, TBS metrics, Data files, Test notes, Bugs, Issues (meta process problems), and the PROOF debrief. The TBS time-breakdown splits each session into T (test design + execution), B (bug investigation + reporting), and S (setup / overhead), plus Opportunity and Idle. Healthy ranges: T 60-80%, B 10-20%, S 10-15%; T under 50% signals trouble.

Full sheet template, the TBS definitions, and the cross-session dashboard metrics: references/session-sheet-and-metrics.md.

PROOF debrief

Every session closes with a PROOF debrief - the five-section report from the original Bach & Bach SBTM paper:

LetterStands for
PPast: what happened in this session
RResults: what was found
OOutlook: what's left to test; suggested follow-up charters
OObstacles: what blocked the tester
FFeelings: tester's qualitative read on quality

The debrief flow: the tester fills the PROOF template within 30 min of session end (memory fades fast); every Result links a bug ID or a confirmed-working item; Outlook names the recommended next charter (the chain to the next session); the lead reviews the debrief with the tester briefly (5-10 min) within 24h before the session sheet is filed, using the checklist in references/session-review-checklist.md. Feelings is the load-bearing field teams skip - the tester's qualitative judgment is signal no metric captures. Aggregated debriefs drive the next round of charters: which areas are well-covered, which are stale, which were never touched.

Full blank template, a fully worked debrief, the quarterly rollup table, and the attention tracker: references/debrief.md.

Worked example

A full 90-minute session (charter, timings, bugs, issues, TBS, PROOF outlook, and how the lead acts on it) is worked through in references/session-sheet-and-metrics.md.

Common confusions

ConfusionReality
"SBTM = ad-hoc testing."SBTM is structured: chartered, time-boxed, reviewed. Ad-hoc has none of those.
"Session sheet = test report."Session sheet captures the journey; test report aggregates outcomes.
"Charters = test cases."Charters state the mission; test cases prescribe steps.
"More TBS time = better tester."Wrong: T% is environment + charter health, not tester skill.
"Sessions need to find bugs to be valuable."Wrong: confirming coverage in a known-clean area is also valuable.
"Exploratory testing = unscripted."Distinct concepts: SBTM is management; unscripted execution is technique. SBTM sessions can be more or less scripted.

Anti-patterns

Anti-patternWhy it failsFix
Sessions > 2 hoursFocus collapses; quality dropsHard 2-hour cap
Multi-charter sessionsLoses focus; metrics ambiguousOne charter per session
Sessions tracked in a spreadsheet that no one reviewsEffort wasted; learning lostLead reviews each session within 24h
Charter as "test X"Doesn't direct explorationUse Explore X with Y to discover Z
TBS metrics never usedThrowaway dataAggregate weekly; drive process change
Bug-finding rate as KPIIncentivises shallow bug-huntingCharter throughput + dashboard health, not bugs-per-session
Session sheets without PROOFLose tester's qualitative signalAlways close with PROOF debrief
All heuristics in one sessionEleven shallow passes crowd out one useful oneCompose 2-3 lenses from the routing table

Limitations

  • Requires tester skill. The framework's value rises with tester expertise; it doesn't make bad testers good.
  • Cadence overhead. Sessions + sheets + reviews add coordination cost - worth it for medium-+ teams, overhead for solo testers.
  • Charter authoring is hard. Vague charters produce vague sessions; charter discipline pays off.
  • Dashboard interpretation requires context. Raw metrics (sessions/week, bugs/session) can mislead without charter framing.
  • Doesn't replace automated coverage. SBTM is for exploration, not regression - pair with automated suites.

References

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

Builds a CI gate that fails the build on **new** WCAG / a11y violations introduced by a PR while grandfathering pre-existing violations on a per-rule / per-page baseline. Aggregates verdicts from axe-core / pa11y / Lighthouse a11y / WAVE / IBM Equal Access scans. Use when a project has accumulated a11y debt and a strict "zero violations" gate would block every PR - the ratchet pattern lets the team ship while preventing regressions.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

Workflow skill that builds an A/B-test validity checklist from an experiment proposal, walking the canonical design-correctness gates - pre-registered OEC/power/guardrails, randomization unit + SRM check, assignment integrity, telemetry, peeking discipline, novelty/primacy, post-experiment SRM re-check - into a per-experiment checklist + sign-off form. Use when launching, auditing, or governing an experiment. For pitfall mechanics (guardrails, peeking) see experiment-results-interpreter's references; to read an already-valid result use experiment-results-interpreter; for per-SDK harness tests use experiment-sdk-testing - this gates DESIGN, not SDK code.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

The single install-flow skill: the reference contract for the PWA install flow (installability gate fields, `beforeinstallprompt` handshake, per-platform paths - Android WebAPK / iOS Share menu / Firefox no-op - and the `display-mode` post-install signal, in references/install-flow-reference.md) plus the build-an-X workflow that emits the Add-to-Home-Screen suite. Walks the four-stage timeline, emitting one test per gate cell per [web.dev/articles/install-criteria][install-criteria], the deferred-prompt → `prompt()` → `userChoice` chain per [web.dev/articles/customize-install][customize-install], the iOS Safari manual-metadata branch (`apple-touch-icon`) per [web.dev/learn/pwa/installation][learn-pwa], and the post-install `(display-mode: standalone)` MQ assertion. Output: a Playwright spec with per-stage cells plus a coverage matrix. Use when a PWA's manifest, icons, or install handler change, when install conversion drops at an unknown stage, or when triaging a flaky install assertion.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

Build-an-X workflow that uses an LLM to map existing tests to spec sections - given a spec doc + the test suite, the LLM identifies which tests cover which sections, surfaces uncovered sections (gap), and recommends specific tests to add. Output is a coverage matrix per spec ID. Scope is mapping tests that already exist and naming the gaps, not authoring tests for new acceptance criteria. Use when a spec doc and a test suite both exist but nobody can say which requirements are actually covered - before a release sign-off, an audit, or a decision about where to spend the next round of test effort.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

Generates tests from natural-language specs (acceptance criteria, user stories, requirements) using an LLM, with confidence scoring per test case (LLM self-assessment plus heuristics: assertion quality, naming, completeness), batching uncertain cases for human review, and integration with the team's existing test framework. Use when the user asks to generate unit tests from acceptance criteria, convert user stories to test cases, automate test creation from requirements, or augment a spec-driven test suite with AI-generated stubs that are then curated before merge.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

Configures Allure Report (test-runner adapter install, `allure-results` directory wiring, `categories.json` for failure classification, `history-trend.json` retention via the copy-history-between-runs pattern), runs the Allure CLI to convert `allure-results` to a static HTML site, and uploads the report as a CI artifact. Use when the team needs richer test reporting than JUnit XML - step-level attachments, per-test history, retry tracking, and severity / epic / feature labeling across framework-agnostic adapters (pytest, Jest, JUnit, TestNG, NUnit, Mocha). As a rich static HTML report generator, it is the open-source alternative to the sunset ExtentReports (JVM/.NET per-test HTML narrative); for hosted cross-run flakiness analytics rather than a static per-run report use currents-integration.

日本語の概要は準備中です。原文の説明を表示しています。

testland/qa132026年10月20日 更新

testland のスキルをすべて見る

このスキルの問題を報告する