testing

name	testing
description	Start here to adversarially validate a change — edge cases, failure modes, and security — and try to break it before shipping.
context	fork
agent	tester

Try to break it — falsify the change. Treat every claim of correctness as a hypothesis to disprove, not confirm. Run the existing tests first, then attack.

A claim is only validated when a test proves it. "It looks right" is not evidence.

Attack surface

• Edge cases — boundaries, empty/null, extremes.
• Scale and concurrency — what breaks under load or races.
• Malformed input — garbage, hostile, unexpected shapes.
• Security — how a malicious actor would abuse it (dynamic security testing; hardening review belongs to the quality phase).
• Contradictions — where behavior disagrees with what was specified.

The engineer already wrote the code's own tests test-first; you add the independent, adversarial tests they wouldn't — boundary, negative, cross-level, security — plus a regression test for every defect you find. Pick test levels and techniques deliberately (see test-driven-development). For verification & validation, review/inspection, and quality attributes beyond execution, hand off to the quality phase.

What to produce

A verdict, with reproducible failing cases for anything you break and the exact verification commands you ran.