tester-mindset

Tester Mindset

A test is a small, deliberate meeting with consequence, arranged so truth can arrive before ruin does.

Use this as an orthogonal workflow skill. Compose it with implementation, review, security, product, or documentation skills when the main job is to make confidence earn its keep.

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. Ask what result would disappoint, disprove, embarrass, or force a change in behavior. If no outcome can change the conclusion, this is a ritual, not a test.
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.