A great manual tester's value is multiplied — or destroyed — by how they work with the people around them. A bug filed as "you broke this" lands very differently from "the system does X when I expected Y." An edge case raised at refinement saves a sprint; raised after launch, it triggers an incident. This lesson is about the collaboration patterns that turn a competent tester into a senior one.
The Three Amigos session
The single highest-leverage collaboration ritual in agile testing is the Three Amigos session. Before any story is committed to a sprint, three people sit down for 30–45 minutes:
- The product owner — explains what and why.
- The developer — explains how it can be built and what is technically risky.
- The tester — explains how it will be verified and what edge cases need answering.
Three viewpoints, one story, one shared understanding. The session works because each role catches issues the other two would have missed. The PM identifies "this conflicts with our refund policy"; the developer identifies "this needs a new database column we don't have"; the tester identifies "we need to know what happens if the user retries within five minutes." Each one of those is a sprint-saver if caught now and a fire-fight if caught later.
What each role brings
For a "forgot password" feature, a Three Amigos session might unfold like this. The PO describes the goal: a user who has forgotten their password should reset it via email within five minutes. The developer notes the dependencies: an email service with rate limits, a token store with an expiry job, a schema change to record reset attempts. The tester asks the questions that turn the goal into testable behaviour — what if the email never arrives? if the user clicks the reset link twice? if the link expires while they are typing the new password? should we lock the account after 5 failed attempts?
By the end of the session, the story has clearer acceptance criteria, the developer has a list of integration tests to add, and the tester has cases drafted before any code is written. Total time: under an hour. Saving: typically a full sprint of "discover-then-fix" later.
The collaboration loop for a single story
For each story in flight, three roles loop through five touchpoints:
Notice the dashed return arrows: the loop is cyclical. A bug fix might reveal a deeper issue that requires re-refining the story. A re-test might find a new bug in the fix. Healthy teams make these loops explicit and short; teams that pretend the loop is one-way end up with bugs deferred indefinitely.
Bug reporting etiquette
Bug reports live forever in the tracker, and the pattern that builds trust is consistent:
- Be factual, not personal. "Search returns wrong results when the query contains an apostrophe" is precise. "You broke the search" is an accusation — same bug, very different reception.
- Lead with the user impact. "Users with Irish or Scottish names cannot search the customer list" is harder to deprioritise than "search fails on input
O'Brien." - Include everything in one shot. Steps, expected, actual, environment, screenshots. Every clarification round costs the developer half a day.
- Acknowledge when you might be wrong. "I think this is a bug, but it might be the spec — could you confirm?" is dramatically more collaborative than "this is broken."
Pairing and trust
Some bugs do not yield to written reports — race conditions, complex state, intermittent reproductions. Twenty minutes of pair-debugging usually beats hours of asynchronous ticket churn. The cost of asking is a Slack message; the saving is hours.
Credibility is built and lost slowly. Verify fixes promptly — a developer whose fix is checked within an hour will work with you again happily; one whose fixes wait three days will start avoiding your bugs. Admit your mistakes quickly — "sorry, was my test data" lands well; defending a bad ticket destroys credibility forever. Share wins publicly — credit the team for fast fixes, not just yourself for the catch. After a few months of this, developers start coming to you proactively: "can you take a look at this before I merge?" That is the strongest signal of a trusted tester.
Handling "is this a bug or a feature?"
When the developer says "that's working as designed" and you disagree: re-quote the acceptance criteria first; if they are silent, pull in the PO for a five-minute decision; if the PO is unavailable, document both interpretations on the ticket and continue rather than block. The pattern is to escalate the question, not the disagreement. Framing matters.
⚠️ Common mistakes
- Filing emotionally-toned bug reports. Even a single hostile bug ticket can damage a working relationship. Re-read everything once before submitting; remove anything that reads like blame.
- Hoarding edge cases. A tester who saves up "gotchas" to spring on the developer at testing time has confused testing with adversarial sport. Surface edge cases at refinement; the team will thank you.
- Avoiding pairing. "I should be able to figure it out from the bug report" is sometimes true and often false. Twenty minutes of pairing on a hard bug saves hours of asynchronous ticket churn.
🎯 Practice task
Spend 25 minutes upgrading your collaboration patterns.
- Open your last 10 bug tickets. Re-read each one as if you were the developer receiving it. Are any phrased accusatorily? Are any missing repro steps or expected behaviour?
- Pick the worst-written one and rewrite it in factual, user-impact language. If it is still open, update the original.
- Identify one upcoming story in refinement and prepare three questions you will ask in the Three Amigos. Frame them around edge cases, error states, and integrations.
- The next time a bug is hard to reproduce, instead of writing more on the ticket, message the developer "got 20 minutes to look at this together?" Notice how much faster it resolves.