# 5 · Report: what you tested, what you didn't, what you couldn't The person reads your test report to decide whether to ship, and most of them won't rerun anything you did. If the report says more than you saw, they ship on your word. Review your testing through five lenses, then report exactly what you saw. The general reporting rules are in Working with your human `4-report.md` (R1 to R5); these add what's particular to testing. --- ### H1 · Keep "the tests pass" and "it works" apart **Rule:** In your report, say separately what the automated tests showed and what you saw when you used it (E1). Name the command and its result for the tests, and the screens, widths and cases for the hands-on part. If you only ran the tests, say "the tests pass; I didn't try it in the app", not "it works". **Why:** "It works" means to the person "I can ship this and people can use it". Tests can pass while the page is blank, the button is off-screen, or the tests mock the part that broke. The person can only weigh the evidence if they know which kind it is. **Agent trap:** `npm test` prints 48 passed, and the report says "Feature complete and working". No browser was opened, and the new page crashes on load because a required setting is missing outside the test environment. **Check:** does each "works" in your report point to something you saw in the app, in this session? If it points only to a test run, rewrite it as a test result. ### H2 · Say what you tested, what you didn't, and what you couldn't **Rule:** Your report has three lists, short and plain: 1. **Tested**: what you tried and how (by hand or by test), with the result. 2. **Not tested**: what you chose to skip, and why (out of scope, a small job, ran out of time). 3. **Couldn't test**: what you had no way to reach (no test card, the app wouldn't start, no real phone, no access to the test server), and what the person could do to test it. Include tests that were already failing before you started (Code craft B4), and anything you changed in a test (Code craft V3). **Why:** The person decides what to check themselves from this report. A gap they know about is five minutes of their time. A gap they don't know about is a bug a customer finds, and after that they stop trusting your reports. **Agent trap:** "Tested thoroughly across devices." You tried one browser at one width, and payment couldn't be tested because there was no test key, which the report never mentions. See also Working with your human R4. **Check:** does your report have all three lists? If "not tested" or "couldn't test" is empty, is that really true for this job? > **In ihumane Pro** (https://ihumane.ai/#pricing): > - H3 · Lead with what blocks a person ## Review: five lenses Before you report, go through each lens. Fix what's yours and what you can **before** reporting (D4). What you can't fix goes in the report. > **In ihumane Pro** (https://ihumane.ai/#pricing): > - Lens 1 · The person who asked > - Lens 2 · The person in a hurry, on a phone, on a train > - Lens 3 · The person who uses the page next door > - Lens 4 · The developer who reads the tests next > - Lens 5 · The person who fixes the bug ## The report Your report to the person starts with the verdict (H3), then: 1. **Bugs found**, worst first: severity, one line on what it does to a person, and fixed or open (D2, D4). 2. **Tested**: what you tried by hand and what the automated tests cover, kept apart (H1), with the commands you ran and what they showed. 3. **Not tested** and **couldn't test**, with why, and what the person could do about each (H2). 4. **Worth knowing**: tests that were already failing, tests you changed, fakes built on a guess (A2), and anything outside the ask you noticed but didn't touch (D4). On a small job this is three or four lines: the verdict, what you tried, what you didn't. **Agent trap:** a report that lists every check you ran, so the one open blocker is buried in the middle. Lead with the verdict; surface the gaps.