01Product-quality risk, test basis, scope, and authority
Provide conflicting requirements, a design, architecture notes, production signals and a release request. Ask the person to define what can be tested and what must first be decided.
Confirm: The person starts with user and business outcomes rather than screens; identifies actors, affected groups, assets and failure consequences; separates product quality, quality in use, process quality and service operation; considers functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility and safety without treating a catalog as complete local requirements; maps research, rules, examples, contracts, designs, code, data, standards, incidents and current behavior as candidate test bases; identifies contradictions, omissions, assumptions and source authority; defines test items, levels, types, objectives, exclusions and completion information; distinguishes likelihood, impact, urgency and uncertainty; ranks risk with accountable owners; states where accessibility, security, privacy, performance, legal or domain specialists are required; and refuses to turn QA preference into product authority.
02Behavior models, test design, coverage, and oracles
Provide a workflow with optional fields, boundary values, role permissions, state transitions, retries and a dependency contract. Ask for a small set of tests whose selection can be explained.
Confirm: The person models actors, preconditions, states, events, decisions, calculations, sequences, concurrency, permissions, data life cycle, interfaces, time and recovery; derives equivalence partitions, boundary values, decision tables, state transitions, branch or structural checks, scenarios, error guessing and useful combinations according to risk; identifies positive, negative, misuse, interruption and recovery paths; distinguishes test condition, case, procedure, data and oracle; uses independent sources or metamorphic and invariant checks where exact expected output is difficult; traces cases to risks and basis items without confusing trace count with meaningful coverage; places fast deterministic checks near the code and reserves integrated paths for boundary behavior; avoids duplicating the same assertion at every layer; reviews requirements, designs and code before executable software exists; and records why each technique can reveal the target fault class and what it cannot show.
03Exploration, automation, data, environments, and diagnosis
Provide a passing regression suite, a shared dataset, an intermittent failure and an unfamiliar feature. Ask how scripted feedback and active investigation should work together.
Confirm: The person charters exploratory sessions with a mission, scope, timebox and useful notes; learns from observations and changes the next test deliberately; preserves queries, state, evidence and follow-up ideas; turns valuable discoveries into reproducible checks where repetition is useful; distinguishes exploration from undocumented clicking; selects automation by feedback value, repeatability, stability, diagnostic quality and maintenance cost rather than automating every case; keeps developers responsible for low-level checks and makes shared ownership visible; avoids brittle UI dependence when a lower boundary expresses the behavior; versions code, tools and dependencies; controls accounts, fixtures, synthetic and masked data, clocks, feature flags, services, devices, browsers and network conditions; never treats copied production data as the default; observes the system as well as the runner; separates product, test, data and environment failures; minimizes retries; assigns flakiness; and diagnoses before quarantining.
04Defect evidence, regression, release advice, and continuity
Provide several failures, an old defect, incomplete coverage and a deadline. Ask for a report that helps owners choose without promising a defect-free release.
Confirm: The person binds results to the exact artifact, configuration, environment, data and time; distinguishes observed behavior, expected behavior, reproduction, evidence, suspected cause, impact, severity, priority and owner; makes intermittent frequency and preconditions visible; avoids duplicate inflation and bug-count targets; links defects to risks and affected paths; retests the correction and selects regression based on change and dependency analysis; reports passed, failed, blocked, skipped, flaky and not-run checks separately; states basis coverage, model coverage, configuration coverage and meaningful gaps without presenting code coverage as product proof; identifies false confidence caused by mocks, stale cases or missing observability; summarizes residual risk and options in plain language; leaves accept defer repair rollback and release authority with named owners; stores testware and decisions in client custody; demonstrates handoff; and retires checks when behavior, architecture, risk or supported configurations change.
