What a good tester submission actually looks like

Developers do not pay for your vibes. They pay for a trail that answers the brief: did you attempt the mission, what happened, and can they see it? A good submission makes approve/reject easy. A weak one forces them to guess — and guesswork gets rejected.

This is what “good” looks like when the test is structured: one path, a short form, a recording.

You followed the mission — not a different one

Read the brief like a checklist. If it says create one project and reach a success state, that is the job. Exploring billing, rewriting the homepage, or “I also tried dark mode” is optional noise unless the brief asked for it.

If you cannot start (bad login, broken link, missing invite), stop early and say so in the form. That is still a useful submission — blocked with proof beats a fake completion.

The form answers match the brief

Every field should map to something they asked. Typical high-signal set:

• Completed the path? (yes / no / blocked)
• Where it broke or got confusing
• Severity (blocker / annoying / cosmetic)
• Anything else they must know before ship (short)

Write so two developers reading two submissions can compare them. “Step 3 — Save never showed a success state” beats “felt clunky.” Skip tourist essays (“overall I liked the colors”).

The recording proves the attempt

Screen recording is not a tour of your desktop. It is the path:

• Start at the URL or sandbox they gave you
• Show the steps in order
• Leave enough of the stall on screen that a stranger can see the problem
• Mark the moment — timestamp or in-product marker — so review jumps to the failure

Twenty minutes of wandering with no marked stall wastes their time and yours. A tight five minutes with a clear fail often wins approval over a long diary.

Comparable beats clever

If three testers run the same brief, the developer wants a pattern: all blocked at invite, or two finished and one hit a role bug. Clever one-off narratives that cannot sit next to each other are hard to trust. Use their words (field labels, step numbers) so answers line up.

What usually gets rejected

• No recording, or a recording that never shows the product
• Form says “completed” but the video stops before success
• Empty severity / empty “where it broke” when you clearly stalled
• Wrong mission — you tested something they did not ask for
• Opinions only: “I’d redesign onboarding” with no evidence from this path

Rejection is not personal. It usually means the evidence was incomplete. Fix the trail and the next claim gets sharper.

A simple self-check before you submit

1. Did I attempt every required step (or mark blocked with why)?
2. Can someone jump to the stall without scrubbing the whole video?
3. Do my form answers match what the recording shows?
4. Would I approve this if I were paying?

If any answer is no, fix it before you send.

On QATested

Testing on QATested is built around that standard: claim a slot, follow the brief, record the session, answer the form, get paid when the developer approves. Start here: tester get started.

Related: how indie developers run a paid QA test · brief, high-signal tests.