원클릭으로 Manus에서 모든 스킬 실행

context-driven-testing

스타1

포크1

업데이트2026년 6월 9일 13:31

Think like a skilled tester — investigate, explore, and report bugs that actually get fixed — in the style of Kaner, Bach & Pettichord's "Lessons Learned in Software Testing" (the context-driven school). Use this skill whenever the user asks how to think like a tester, how to do exploratory testing or write a charter, how to design a testing approach for their specific situation, what an oracle or heuristic is, how to write a bug report that gets fixed, whether a testing metric or "best practice" is meaningful, or what manual testing and automation are each good for — even if they never mention the book or its authors. Also for questions like "how should we test this", "is 100% automation realistic", "why isn't this bug getting fixed", or "what makes a good exploratory testing session". This skill is mindset/strategy advisory, not write-this-unit-test (use khorikov-unit-testing / effective-software-testing for that). Enforces: there are no best practices, only practices that fit a context; testing is investig

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

arcboxlabs

arcboxlabs/testing-canon

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Lessons Learned in Software Testing (Kaner, Bach & Pettichord)

This skill installs a way of thinking about testing, not a procedure. Where the rest of the repo tells you how to build a good test, this tells you how to be a good tester: testing is a skilled, investigative, thinking activity — you're learning about a product to inform the people who decide its fate, under real constraints of time and uncertainty. The book's stance is the context-driven school: judgment and skill over rote process, heuristics over "best practices."

Reach for this for the human, investigative side of quality: planning how to test a specific situation, doing exploratory testing, reasoning about what could go wrong, deciding what's worth automating, and writing bug reports that change minds. It is the mindset behind Quadrant 3 of agile-testing-quadrants.

This skill is advisory; it produces strategies, charters, and bug reports rather than unit-test code.

The seven basic principles

The context-driven school is defined by seven principles (use them as a checklist when someone proposes a "best practice"):

The value of any practice depends on its context.
There are good practices in context, but there are no best practices.
People, working together, are the most important part of any project's context.
Projects unfold over time in ways that are often not predictable.
The product is a solution. If the problem isn't solved, the product doesn't work.
Good software testing is a challenging intellectual process.
Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.

The practical upshot: never recommend a testing practice in the abstract. Ask who, when, where, why, and what-if first — the same technique that's essential for an avionics system may be wasteful for a throwaway web app. Detail and illustrations in references/context-driven-principles.md.

Testing is investigation, not verification

The central mental shift: testing isn't mechanically confirming the program does what the spec says (that's checking). Testing is investigating to discover what's actually true about the product — including the things no one thought to specify. A tester is an information service: the job is to reduce stakeholders' uncertainty so they can make good decisions (ship / fix / cut), not to be a gatekeeper who "owns" quality. Different missions (qualify it, debug it, sell it, explore it) call for entirely different testing.

This is why the value of a test lies in the information it provides — a test that can only ever pass tells you little; a test aimed at a real risk, that could plausibly fail, tells you a lot.

Exploratory testing

Exploratory testing is simultaneous learning, test design, and test execution: you design the next test based on what the last one just taught you, rather than following a script written in advance. It's not "random clicking" — it's disciplined, often organized around a charter (a mission for a time-boxed session: "explore the import feature with malformed files to discover data-loss risks"). It excels exactly where scripted tests are weak: finding the surprises, the unspecified behavior, the "I didn't think of that." Scripted tests and exploration are complementary — scripts confirm known expectations cheaply and repeatably; exploration finds the unknown. Detail (sessions, charters, bug hunting) in references/exploratory-testing-and-heuristics.md.

Oracles and heuristics

Two ideas you'll use constantly:

An oracle is the means by which you decide whether a behavior is a problem — a reference, a comparable product, a spec, a user's reaction, your own judgment. The load-bearing lesson: all oracles are fallible. A program can "pass" your test and still be broken in a way you weren't watching. So hold your pass/fail judgments provisionally, and use multiple oracles (consistency heuristics: is the product consistent with comparable products, with its own past behavior, with its claims, with reasonable user expectations?).
A heuristic is a rule of thumb — a fallible-but-useful way to generate test ideas fast. Because the space of possible tests is infinite, good testers collect heuristics to make better guesses about which few tests will be worthwhile. The crucial caveat: "there is no wisdom in heuristics — the wisdom is with you." A heuristic only makes a suggestion; understand why it works and when it doesn't, rather than following it blindly. (Every heuristic is also a bias.)

Bug advocacy: report to get fixed

Finding a bug is half the job; getting it fixed is the other half. A bug report is an advocacy document — effectively a sales tool arguing that the bug is worth scarce time and money to fix. Your responsibility isn't that every bug gets fixed; it's to report accurately and vividly enough that the reader grasps the full impact and can decide well. Practical moves (full detail in references/bug-advocacy-and-reporting.md):

Make the impact clear — how it interferes with real use, what data it corrupts, how often users will hit it. State the benefit of fixing so the reader wants to.
Do follow-up testing — a minor-looking bug often hides a more severe consequence; probe it before reporting so you report the worst, most motivating version.
Anticipate objections — pre-empt "works on my machine," "edge case," "won't fix."
Mind your tone — reports shape your credibility; blaming or sloppy reports get you (and your future reports) ignored. You are what you write.

Healthy skepticism

The context-driven stance breeds productive skepticism — apply it when steering testing:

Metrics: invalid metrics are dangerous. Counting test cases, or chasing a coverage percentage, measures activity, not quality, and distorts behavior once it becomes a target. (Same "guide, not target" line as effective-software-testing.)
"Best practices": there aren't any in the abstract (principle 2). Treat any one-size-fits-all prescription — including the other skills in this repo — as a default to adapt, not a law.
Automation: automated checking ≠ automated human testing. Be skeptical of "100% automation" claims; automation runs fewer tests more often, and many valuable tests are worth running only once (by a human). Automate to free people for the investigation only people can do.
Documentation: test artifacts are worth only as much as they serve a real stakeholder need; heavy documentation for its own sake is waste.
"Good enough": the question is rarely "is it perfect" but "is it good enough for this context, and how would we know if it weren't?" — a risk judgment, made with stakeholders.

Where this fits with the other skills

This is the highest-altitude, most human skill in the repo. It complements rather than competes with the others:

It is the mindset behind Q3 (exploratory/usability) in agile-testing-quadrants.
Its heuristics for generating test ideas pair with the systematic case-derivation of effective-software-testing (exploration finds risks; spec-based testing covers them methodically) — its combination/all-pairs lesson is the same pairwise idea.
It supplies the why test this at all / how much is enough judgment that the unit-craft skills (khorikov-unit-testing, art-of-unit-testing) assume.

Reference files

references/context-driven-principles.md — the seven principles in depth, their illustrations, and the context-driven mindset (testing as a service, missions, no best practices).
references/exploratory-testing-and-heuristics.md — exploratory testing and charters, oracles and their fallibility, consistency heuristics, and using heuristics wisely.
references/bug-advocacy-and-reporting.md — bug advocacy, the report as a sales tool, follow-up testing, and what makes a report get the bug fixed.

../../EXAMPLES.md (repo root) has worked examples under "Lessons Learned in Software Testing" — investigative artifacts (a charter, a weak-vs-strong bug report) rather than code.

이 저장소의 다른 Skills

같은 저장소

agile-testing-quadrants

arcboxlabs/testing-canon

Plan a team's test strategy and decide what kinds of testing a product actually needs, using Lisa Crispin and Janet Gregory's "Agile Testing" — the Agile Testing Quadrants, the whole-team approach to quality, and an explicit definition of "done." Use this skill whenever the user asks what kinds of tests they need, how to plan testing for a feature or release, where exploratory / performance / usability / acceptance / security testing fit, who owns quality on a team, what "done" should mean, how to balance manual vs. automated testing, or how to shape a test-automation strategy — even if they never mention the book or Crispin & Gregory. Also for questions like "what should our test strategy be", "do we even need exploratory testing", "what's our definition of done", or "how do we split testing work across the team". This skill is strategy/process advisory — for writing an individual unit test use khorikov-unit-testing / art-of-unit-testing. Enforces: classify testing with the four quadrants; treat quality as a

2026-06-091

art-of-unit-testing

arcboxlabs/testing-canon

Write, organize, name, and tame unit tests in the style of Roy Osherove's "The Art of Unit Testing" — trustworthy, maintainable, readable tests built around a unit of work's entry point and exit points. Use this skill whenever the user asks you to write or scaffold unit tests, name or structure a test, choose between a value / state / interaction test, set up or avoid a mocking (isolation) framework, or clean up tests that are brittle, flaky, over-mocked, or unreadable — even if they never mention the book or Osherove. Also use it for questions like "how should I name this test", "why is this test so brittle", "is this a stub or a mock", or "how many asserts per test". Enforces: assert an exit point (observable behavior), never an internal call; never verify a stub; one concern per test with no logic in the test body; and prefer value/state tests over interaction tests.

2026-06-091

effective-software-testing

arcboxlabs/testing-canon

Systematically derive test cases — and judge how thorough a test suite is — in the style of Maurício Aniche's "Effective Software Testing." This is the "how do I come up with the right inputs" complement to behavior-focused unit testing. Use this skill whenever the user asks what test cases to write, how to cover a function or method, how to find missing edge cases, what to test at a boundary, how to test a complex boolean condition, whether a suite is thorough enough, how to use code coverage well, whether to reach for property-based testing, or how to make a class testable — even if they never mention the book or Aniche. Also for questions like "what inputs should I test here", "is 100% coverage enough", "how do I test all these combinations", or "why is this class so hard to test". Enforces: derive cases from the specification first (partitions + boundaries); use coverage as a guide to find gaps, never as a target; and design for controllability and observability.

2026-06-091

khorikov-unit-testing

arcboxlabs/testing-canon

Write and review unit tests in the style of Vladimir Khorikov's "Unit Testing Principles, Practices, and Patterns" (the classical/Detroit school). Use this skill whenever the user asks you to write, add, generate, scaffold, fix, refactor, audit, or review unit tests or a test suite — even if they never mention Khorikov or the book — and whenever you are about to write tests as part of a larger coding task. Also use it for questions like "what should I test here", "should I mock this", "why is this test brittle/flaky", "is this a good test", or "how should I structure this test". The skill enforces four rules above all: test OBSERVABLE BEHAVIOR not implementation details; maximize resistance to refactoring (no false failures); mock ONLY unmanaged out-of-process dependencies; and do NOT write tests for trivial code.

2026-06-091

legacy-code-testing

arcboxlabs/testing-canon

Get untested, hard-to-change ("legacy") code safely under test using Michael Feathers's "Working Effectively with Legacy Code" — find seams, pin current behavior with characterization tests, and break dependencies so tangled code becomes testable. Use this skill whenever the user inherits or works with code that has no tests, is hard to instantiate or hard to run in a test, is tightly coupled, or "can't be tested without rewriting it"; whenever they need to change scary code safely, wrap a test harness around it, or break a dependency on a database, singleton, global, static, or `new` — even if they never mention the book or Feathers. Also for questions like "how do I test this untested class", "how do I break this dependency", "how do I change this safely when there are no tests", or "where do I even start with this legacy code". Enforces: legacy code = code without tests; pin actual behavior with characterization tests before changing; break dependencies at a seam (don't rewrite blind); and prefer Sprout/Wr

2026-06-091

xunit-test-patterns

arcboxlabs/testing-canon

Diagnose and fix messy, brittle, flaky, slow, or duplicated test suites using Gerard Meszaros's "xUnit Test Patterns" — the canonical catalogue of test smells and the patterns that remove them, and the authoritative Test Double taxonomy (Dummy, Stub, Spy, Mock, Fake). Use this skill whenever the user asks you to clean up, refactor, de-duplicate, or speed up tests; whenever tests are obscure, fragile, erratic/flaky, or full of copy-paste setup; whenever you need the precise difference between a stub, spy, mock, fake, or dummy; or whenever you're designing fixtures and setup/teardown — even if they never mention the book or Meszaros. Also for questions like "why are my tests so flaky/slow", "how do I share setup without coupling tests", "is this a stub or a mock", or "how do I stop duplicating test setup". Enforces: name the smell before fixing it; verify one condition per test; prefer a Fresh Fixture over a Shared Fixture; and use the five-name Test Double taxonomy precisely. This skill owns the repo's referen

2026-06-091

name

context-driven-testing

description

Lessons Learned in Software Testing (Kaner, Bach & Pettichord)

This skill is advisory; it produces strategies, charters, and bug reports rather than unit-test code.

The seven basic principles

The context-driven school is defined by seven principles (use them as a checklist when someone proposes a "best practice"):

The value of any practice depends on its context.
There are good practices in context, but there are no best practices.
People, working together, are the most important part of any project's context.
Projects unfold over time in ways that are often not predictable.
The product is a solution. If the problem isn't solved, the product doesn't work.
Good software testing is a challenging intellectual process.
Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.

Testing is investigation, not verification

This is why the value of a test lies in the information it provides — a test that can only ever pass tells you little; a test aimed at a real risk, that could plausibly fail, tells you a lot.

Exploratory testing

Oracles and heuristics

Two ideas you'll use constantly:

An oracle is the means by which you decide whether a behavior is a problem — a reference, a comparable product, a spec, a user's reaction, your own judgment. The load-bearing lesson: all oracles are fallible. A program can "pass" your test and still be broken in a way you weren't watching. So hold your pass/fail judgments provisionally, and use multiple oracles (consistency heuristics: is the product consistent with comparable products, with its own past behavior, with its claims, with reasonable user expectations?).
A heuristic is a rule of thumb — a fallible-but-useful way to generate test ideas fast. Because the space of possible tests is infinite, good testers collect heuristics to make better guesses about which few tests will be worthwhile. The crucial caveat: "there is no wisdom in heuristics — the wisdom is with you." A heuristic only makes a suggestion; understand why it works and when it doesn't, rather than following it blindly. (Every heuristic is also a bias.)

Bug advocacy: report to get fixed

Make the impact clear — how it interferes with real use, what data it corrupts, how often users will hit it. State the benefit of fixing so the reader wants to.
Do follow-up testing — a minor-looking bug often hides a more severe consequence; probe it before reporting so you report the worst, most motivating version.
Anticipate objections — pre-empt "works on my machine," "edge case," "won't fix."
Mind your tone — reports shape your credibility; blaming or sloppy reports get you (and your future reports) ignored. You are what you write.

Healthy skepticism

The context-driven stance breeds productive skepticism — apply it when steering testing:

Metrics: invalid metrics are dangerous. Counting test cases, or chasing a coverage percentage, measures activity, not quality, and distorts behavior once it becomes a target. (Same "guide, not target" line as effective-software-testing.)
"Best practices": there aren't any in the abstract (principle 2). Treat any one-size-fits-all prescription — including the other skills in this repo — as a default to adapt, not a law.
Automation: automated checking ≠ automated human testing. Be skeptical of "100% automation" claims; automation runs fewer tests more often, and many valuable tests are worth running only once (by a human). Automate to free people for the investigation only people can do.
Documentation: test artifacts are worth only as much as they serve a real stakeholder need; heavy documentation for its own sake is waste.
"Good enough": the question is rarely "is it perfect" but "is it good enough for this context, and how would we know if it weren't?" — a risk judgment, made with stakeholders.

Where this fits with the other skills

This is the highest-altitude, most human skill in the repo. It complements rather than competes with the others:

It is the mindset behind Q3 (exploratory/usability) in agile-testing-quadrants.
Its heuristics for generating test ideas pair with the systematic case-derivation of effective-software-testing (exploration finds risks; spec-based testing covers them methodically) — its combination/all-pairs lesson is the same pairwise idea.
It supplies the why test this at all / how much is enough judgment that the unit-craft skills (khorikov-unit-testing, art-of-unit-testing) assume.

Reference files

references/context-driven-principles.md — the seven principles in depth, their illustrations, and the context-driven mindset (testing as a service, missions, no best practices).
references/exploratory-testing-and-heuristics.md — exploratory testing and charters, oracles and their fallibility, consistency heuristics, and using heuristics wisely.
references/bug-advocacy-and-reporting.md — bug advocacy, the report as a sales tool, follow-up testing, and what makes a report get the bug fixed.

../../EXAMPLES.md (repo root) has worked examples under "Lessons Learned in Software Testing" — investigative artifacts (a charter, a weak-vs-strong bug report) rather than code.