Yesterday you ran a thirty-minute session with a charter and closed it with a debrief. Today you see where all of that work lives inside a team’s week.
Everything you have practised so far happens inside a rhythm of meetings and hand-offs. Knowing that rhythm is the difference between a tester who waits to be handed work and a tester the team leans on.
The week, meeting by meeting
- Refinement. The team reads upcoming stories together and agrees what done means. You met this room on Day 2, and it is where your questions carry the most weight, because nothing is built yet. Ask about missing criteria, about edges, about error states. A gap raised here costs the team five minutes. The same gap found after release costs real users.
- Standup. A short daily meeting, usually ten minutes standing up, where each person says what they did, what they are doing next, and what is blocking them. Yours is simple: what you tested, what you found, what you are waiting on. “I am blocked because the test environment is down” said out loud at 9 a.m. saves the whole day. Testers who sit on blockers lose days quietly.
- Triage. The meeting where new bug reports are reviewed and the team decides what gets fixed, and when. This is where Day 5 pays off again: severity is how badly it breaks the product, priority is how urgently it should be fixed, and triage is the room where those two get argued. You are the person who has actually seen the bug, so come with the evidence: steps, exact data, who is affected. A report that answers the room’s questions before they are asked gets scheduled; a vague one gets parked.
- The release. At some rhythm, weekly for some teams, daily for others, the team decides what ships. This is where your test results, your open bugs, and your judgment come together in a summary. You practise that call in full on Day 10.
Working with developers
Half your effectiveness in all four rooms comes down to one relationship, so here is what a decade of it has taught me:
- Report the behaviour, never the person. “The total goes stale when an item is removed” gets investigated. “Your cart code is broken” gets defended. Same bug, different afternoon.
- Bring evidence, not opinions. Steps, data, screenshots. The reports you wrote this week are already this shape.
- Ask early, in refinement, not late, in triage. Every question you ask before the code exists is a bug that never gets written.
- Give the good news too. “I hammered the search with everything on my list and it held” builds the kind of trust that gets your bug reports believed on a bad day.
A bug report is about the product, never about the person who built it.
Do this well and something shifts: developers start showing you things before they ship, asking “what would you try on this?” while it is still on their machine. That is when the job gets good, because you stop finding bugs and start preventing them.
Do this today
Take the discount bug from Day 5 and prepare it for triage, three lines:
- One sentence stating the behaviour and who is affected.
- Your severity, with the reason.
- Your priority, with the reason.
Then say it out loud once and time yourself. If it takes more than thirty seconds, tighten it. Keep the three lines with your reports; that little triage case is a shape you will reuse in every bug meeting of your career.
Tomorrow: the map of what to learn after this course, in the order that pays off.