Ask any tester for a sample bug report before you hire them. It is the only artifact that shows how they think, and you do not need to be technical to judge it.
Here are five checks. They take ten minutes and they are more reliable than any interview.
Check 1: Can you follow the steps without asking a question?
Read the reproduction steps as if you were going to perform them. Count how many times you would need to ask what something means.
Good:
- Open the store on iPhone 13, Safari 17
- Add any product to the basket
- Go to checkout
- Enter postcode "1" and leave all other fields correct
- Press Continue
Bad:
Checkout fails validation on mobile with bad input
The second is not a bug report. It is a note the tester wrote for themselves. A developer receiving it has to reproduce the investigation before starting the fix, which is most of the work.
The count of questions you would need to ask is your quality score. Zero is what good looks like.
Check 2: Does it separate what happened from what should have happened?
Every real report has three parts: steps, actual result, expected result.
The expected result is the one that gets skipped, and it is the one that matters. It is where the tester states their understanding of how the product should behave. If it is missing, you cannot tell whether they found a bug or misunderstood the feature.
It also shows judgement. "Expected: the other seven fields keep their values" tells you the tester knows why this matters. "Expected: it works" tells you nothing.
Check 3: Is the environment recorded?
Browser, version, device, operating system. On every issue, not in a note at the top of the document.
Half of front-end bugs are environment-specific. A report without environment details sends a developer hunting for something that only happens on Safari, in Chrome, for an hour.
Check 4: Is there a severity rating, and does it make sense?
Ask for severity on every issue. Then check whether you agree.
The revealing case is a report where everything is critical. That tester is not prioritising — they are handing you their raw list and making you do the triage. A tester with judgement will tell you which three issues block your launch and which twelve can wait, and will be right.
Look for severity that reflects business impact rather than technical drama. A misaligned footer is cosmetic. A checkout that accepts an invalid card is critical, even though the code change is smaller.
Check 5: Did they find something a script would not have?
Scan the sample for one issue that required a person.
A missing button is machine-findable. What you want to see is something like: the confirmation email says "undefined" in the customer name field, or the flow works but the second step contradicts the first, or the error message tells the customer to do something impossible.
If every issue in the sample could have been caught by an automated check, you are paying a person to do a machine's work.
The extra question worth asking
"What did you decide not to report, and why?"
A good tester filters. They found forty things and reported twenty-eight, because twelve were duplicates, intentional, or too trivial to spend your developers' attention on.
A tester who reports everything they saw has not done the hardest part of the job, which is judgement about what deserves your time.
What a sample cannot tell you
Whether they will meet a deadline. Whether they communicate well mid-engagement. Whether they will tell you honestly when they have not finished.
Those only show up in real work, which is why buying one small engagement first beats any amount of evaluation. A single flow, a few hundred dollars, a few days. You learn everything a sample cannot show.
You can see the reports we produce here, and our smallest package is $349 if you would rather judge by real work than by a sample.