Part 3 answers: Can we see and steer what matters?
A test finds a bug only if three things happen: the stimulus activates it, the wrong value propagates somewhere visible, and a check notices. Controllability is the ability to drive the design into the state you need; observability is the ability to see a wrong value when it appears.
This part explains why a test can trigger a bug and still pass, the trade-off between black-box and white-box checking, the power and danger of backdoors and test modes, and what designers can do to make verification cheaper.
Explain activation, propagation and detection.
Diagnose why a test that hit a bug still passed.
Decide where checks should look inside a design and what hooks to ask designers for.
Answer each in your head before opening it. If two or more feel shaky, revisit Part 2: Specifications as Checkable Rules first.
Every check needs something that knows the correct answer; building and trusting that oracle is often the hardest part.
So each rule maps to a check, a coverage point and a result, and disagreements can be pinned to a rule.
Yes: one that forbids behaviour the specification allows fails legal designs and wastes debug time.
# | Lesson | Level | Status |
|---|---|---|---|
3.1 | W · Working | Ready | |
3.2 | W · Working | Ready | |
3.3 | S · Senior | Ready | |
3.4 | W · Working | Ready | |
3.5 | S · Senior | Ready | |
3.6 | P · Principal | Ready | |
— | all levels | Ready |
Every lesson in this part is ready. Work through them in order: each one sets up the problem the next one solves.
This course teaches the decisions behind verification. These lessons teach the tools and syntax that carry them out, so this part links to them instead of repeating them.