Answer each question out loud before opening it. If you miss more than three in the checkpoint, revisit the lessons linked at the end.
Scope, features traced to the specification, risk, method and level per feature, checks and coverage, resources, schedule, done criteria and a change process.
Extract features from functions, interfaces, configurations, errors, interactions and non-functional requirements, then review them with designers.
By risk (likelihood, impact, difficulty of detection), weighting effort toward risky features but keeping some effort on every feature.
A bottom-up range with named drivers and an explicit reserve for debug, closure and change, re-estimated at milestones.
None alone: read pass rate, coverage and bug trends together and against the plan's features with evidence.
In tiers by frequency (commit, nightly, weekly), ordered and selected by value, with same-day triage and logged seeds.
Impact analysis, a re-verification plan with a cost, a decision (prefer default-preserving changes), and residual risk recorded for sign-off.
Task. You have eight weeks to verify a new interrupt controller (32 sources, priorities, masking, edge and level modes, a power-down mode) with two engineers. Sketch the plan: features, the five riskiest and why, method per feature, the regression tiers, and what you would report each week.
Features: raise and clear per source; edge versus level detection; priority resolution; masking and unmasking with interrupts pending; nesting and pre-emption; register access and reset values; power-down with interrupts pending and wake on interrupt; simultaneous raises; clear racing a new raise; performance (latency from source to output). Riskiest five: simultaneous raises at different and equal priorities (concurrency); clear racing a new raise on the same source (race); level-mode source still asserted after clear (a classic lost or repeated interrupt); unmask with pending interrupts (mode interaction); wake from power-down (rare path, a missed wake is a hang). Methods: formal for priority resolution, masking and the clear/raise race; constrained random with a scoreboard predicting the output for everything else; directed tests and a register app for registers and reset; power-aware simulation for power-down. Regression: commit check with smoke and the formal proofs; nightly random with fresh seeds; weekly many seeds and a planted-bug run. Weekly report: features with evidence against the plan, coverage holes by cause, bug discovery rate, open bugs by severity, and the estimate range updated.
A plan starts from what must be true and records method, evidence and done per feature; a test list only records what exists.
Functions, interfaces, configurations and modes, errors, interactions, non-functional requirements.
48.7%, 53.7% and 42.6%.
Noisy estimates left real risk in features that got no effort.
Debug, coverage closure and change absorption.
100%, with a third of the features (10 of 30) never tested and 10 bugs in them.
The testbench's strength: a drop in bugs caught means a check was weakened.
The change's new behaviour is untested by the existing regression.
28.
F25 (low power disabled) and F28 (reset mid-traffic); F26 (throughput) had only partial evidence.