tester-mindset

Tester Mindset

Design evidence that can reveal a meaningful failure in the claim being tested. Use this as an orthogonal workflow alongside the relevant domain guidance.

For planning or review, return a strategy or findings without editing code or changing external state. For exploratory work, run only authorized, bounded probes. Existing implementation authority covers relevant test changes; do not turn design feedback into an unrelated production refactor.

Load exploration and oracle prompts when a context map, risk category, test-idea tour, or alternative perspective would expose a missing case. Do not exhaust those catalogs for routine work.

When To Use

• design a test plan, validation strategy, QA approach, or acceptance criteria
• identify edge cases, failure modes, adversarial cases, or missing evidence
• decide whether existing tests, metrics, benchmarks, or demos prove enough
• plan or debrief exploratory testing, chartered sessions, or bug hunts
• review test quality and detect weak, tautological, or proof-theater tests
• turn a vague claim such as "this works" into observable checks
• review a change through the question "what consequence was invited?"

Not For

• simply running an existing test command
• broad debugging when the failure is already reproduced and the next step is diagnosis
• security exploit analysis that needs the full security workflow
• routine implementation work where ordinary repo validation is enough

Core Workflow

1. Map the context. Identify the mission, stakeholders, risks, constraints, team skills, available evidence, and cost of being wrong. There are no universal testing best practices, only practices that fit a context.
2. Name the claim. State the belief being tested in falsifiable language. If the claim is vague, split it into behavior, contract, performance, safety, usability, security, trust, maintenance, or process claims.
3. Separate testing from checking. Checking applies explicit pass/fail rules to known expectations. Testing is investigation: learning, modeling, exploring, questioning, and interpreting. Automate checks, but do not pretend automation replaces judgment.
4. Invite consequence. Name an observation that would disprove the claim or change the next action. If no outcome could change the conclusion, revise the probe.
5. Choose a survivable scale. Make the test strong enough to teach and small enough to survive. Prefer cheap probes first, then increase fidelity where risk, irreversibility, or user harm justifies it.
6. Choose oracles deliberately. Name how a problem would be recognized: requirements, prior behavior, comparable products, standards, stakeholder expectations, user goals, internal consistency, product purpose, statutes, or expert judgment. Treat every oracle as fallible.
7. Inspect the apparatus. Question fixtures, mocks, datasets, metrics, timing, environments, prompts, observers, and definitions of "pass." A failing test may expose a broken question, not only a broken system. Ask whether the fixture, mock, metric, benchmark, prompt, dataset, or environment is the thing actually being validated.
8. Let reality disagree. Include paths that can contradict the preferred story: boundary data, malformed input, slow dependencies, retries, concurrency, time, state transitions, upgrade paths, human behavior, adversarial pressure, or conflicting stakeholder values.
9. Interpret narrowly. Say what the result proves, what it only suggests, who it matters to, and what remains untouched. Passing evidence reduces uncertainty; it does not convert partial coverage into certainty.
10. Choose the next consequence. If risk remains material, recommend the next smallest higher-fidelity check: integration test, exploratory session, benchmark, canary, monitoring, user trial, chaos probe, manual smoke, or review.