Archive note
Testing sprint field notes, second day
What the second day of a concentrated testing sprint looks like when the easy wins are gone and the hard questions arrive.
The second day of a testing sprint has a different texture from the first. The room is quieter. The obvious fixes are gone. People are deep in the part of the work that does not fit neatly into a task list.
Morning triage
The first hour is usually spent deciding what "done" means for the day. A failing test might be a real bug, an outdated assumption, or a problem with the test itself. Sorting those three cases is slower than writing new code, and it is the most valuable work in the room.
A useful habit is to write the diagnosis on the shared board before touching the code. One line: what we expected, what happened, and who is looking. That small note prevents two people from investigating the same failure from opposite ends.
The hard middle
By midday the remaining failures tend to cluster around state. A test passes alone and fails in a group. A fixture leaves something behind. A permission check depends on a setting that another test changed. These are not glamorous problems, but they are where a suite earns trust.
The temptation is to skip the test or loosen the assertion. Resist it long enough to understand the interaction. A skipped test is a decision to stop learning about that part of the system.
When a failure takes more than twenty minutes, pair up. One person reads the code aloud while the other follows the flow. The act of explaining usually locates the assumption faster than another round of guessing.
Shared repository discipline
A sprint works best with a short, visible commit rhythm. Small commits, clear messages, and a quick check before pushing. The goal is not a perfect history. It is a history that a person who was not in the room can follow tomorrow. The SimpleTest project is a reminder that the tool is only as good as the conventions around it.
Review is part of the work, not a reward at the end. Reading each other's tests during the sprint catches more confusion than reading them a week later, when the context has evaporated.
Closing the day
The last half hour should be boring on purpose. Record what changed, what is still failing, and what the next person should try first. A sprint that ends with a clear list is easier to continue than one that ends with a heroic push and no notes.
By the end of the second day, the useful output is not only passing tests. It is a shared mental model of the system, held by more than one person.