Archive note
Testing sprint field notes, first day
Setup, shared tools, and the social work of getting a room full of contributors to test the same code in the same way.
The first day of a testing sprint is mostly logistics disguised as code. A room, a shared repository, a way to run the suite, and a clear first task. Get those four things right and the rest of the day has a chance.
Set the scope before the laptops open
A sprint without a boundary becomes a tour. Decide which area of the code the room will touch and write it somewhere visible. "Today we are working on the tests around publishing" is a scope. "Let us improve testing" is a mood.
The scope should be small enough that two people can explain it to a newcomer in a minute. If it takes longer, split it and pick the part with the most uncertainty.
Make the first run easy
Nothing drains a room faster than a setup step that only one person understands. Spend the first hour making the test command work for everyone, including the person who arrived late. A short written setup note is worth more than a long verbal explanation. The Drupal documentation is a good starting point, but the local notes still matter.
Check the boring things: the right version of the runtime, a clean database, and a known starting point. Most mysterious failures on day one are environment differences in disguise.
Pair the room deliberately
Pairing experienced contributors with newcomers is useful, but not if the newcomer only watches. Give each pair a task with a clear end, and ask the less experienced person to drive. Watching someone type is not the same as learning.
Ask every pair to write one sentence about what they learned before lunch. Read them aloud. The repetition reveals which part of the setup is still confusing.
Keep a visible queue
A board with three columns is enough: ready, doing, done. Every item should be small enough to finish in a session. Large items go back to the planning list. The queue is a promise that no one is expected to hold the whole plan in their head.
End with a handover
The last task of the day is not another fix. It is a note for tomorrow: what is failing, where it fails, and what has already been ruled out. Write it in the shared place, not in a private draft.
A good first day leaves the room tired but oriented. The code will still have problems. The difference is that the problems now have names and owners.