break

Topics in the source

• Break
• 1. Scope one component
• 2. Infer the scenarios from the component
• 3. Build the harness page
• 4. Look once
• 5. Report what broke and stop
• 6. Leave the page up, delete it on request
• Before you finish

This skill takes one component and renders it on a harness page under every scenario that can actually reach it. That page is the deliverable: a visual report the user scrolls through, every scenario side by side, with the breaks marked. It observes rather than judges. A finding here is something that visibly broke on the page, named in the vocabulary of the domain skill that owns the fix. Reviewing code against a standard is interface-review and better-interface; exploring design alternatives is variant; working through a component's product states one at a time is state-machine. Where variant insists on the real page, this skill isolates on purpose. You are not judging how the component looks in context. You are checking whether it defends itself when the content is worst-case. The whole run is build, look once, report: minutes, not a session. Nothing in it justifies instrumentation, browser debugging or a second pass. One component per run. "The settings page" is not a component; the profile form's text input is. Where the request spans several, list the candidates and ask which one to test. Restate what the component is in one sentence: what it accepts, what it renders and wher

This is an excerpt. Refer to the complete source and its current requirements.