Do not send a tester a link and say ‘test everything’. That sounds comprehensive and tells them almost nothing.
A decent tester will work out a lot for themselves, but you will get more value if they know what the product is for, what has changed and what would be painful if it failed.
If you are bringing somebody in and are not sure what to ask for, that is something we can help shape before anybody starts clicking.
Tell them what matters, not just what exists
Give them the important user journeys and the business consequence of failure. If customers pay, tell them how payment works. If users can cancel, refund, recover an account or delete data, say so. If an external service is critical, identify it. If one feature is only used by an administrator twice a year, that matters too.
Also tell them what changed. A tester should spend more time around new code, shared components and anything the change could disturb than around a page nobody has touched since 2023. When a change could disturb shared components, agree a sensible regression-testing scope rather than simply handing over an ancient checklist.
Give them usable test accounts, realistic data, the devices or browsers that actually matter and any known environment limitations. Watching a tester burn half the booking trying to obtain a login is a very efficient way to purchase no testing.
Agree what kind of testing you are buying
For a small app, paying someone twenty bucks to have a poke around can be useful. They may find broken links, confusing flows, obvious validation problems and things you have simply stopped noticing.
That is different from asking an experienced tester to work out where the real risk sits, design coverage around it, challenge what has already been tested and tell you whether there are important gaps before launch.
Neither purchase is automatically better. The stupid bit is paying for the first and assuming you received the second because the gig description said ‘professional QA’.
Make sure failure gets tested
Do not ask only whether the normal journey works. Ask what happens when the payment succeeds but the confirmation fails, when the same action is submitted twice, when a session expires halfway through, when an integration is unavailable, or when one user tries to access another user’s data.
You do not need to invent every possible disaster. Focus on failures that could lose money, lose data, trap a customer or leave your business manually repairing things afterwards.
A testing brief you can actually send
You can copy and adapt this example. It is deliberately short; a tester needs a useful target, not your entire product backlog.
Product: A web app for booking appointments and paying a deposit. Release: New cancellation and refund handling. Deadline: Please complete an initial check by Thursday afternoon. Access: Staging URL, two test accounts, payment sandbox credentials and supported browser/device list to be supplied securely.
- Please prioritise: New customer booking, deposit payment, confirmation, cancellation, refund, and preventing two customers taking the same slot.
- Please challenge: Duplicate clicks, expired sessions, payment failures, interrupted refunds, permissions between different customer accounts and attempts to book unavailable times.
- Known limitations: The sandbox sends test notifications and does not process real refunds. State clearly where those limitations prevent a trustworthy result.
- Please deliver: Reproducible defects with screenshots or logs, a short list of journeys checked, untested areas, the build/browser details and a recommendation on the biggest remaining risks.
Ask the tester to tell you quickly if the environment, credentials or product behaviour stop the work. Also agree in advance whether you are buying an exploratory session, a targeted release assessment or a repeatable regression pack; they are different jobs. A list saying ’37 tests passed’ without explaining what those tests proved is not much of a handover.
Ask for evidence you can actually use
You want clear defects with enough information to reproduce them, a short explanation of what was covered, important areas that were not covered and any risks the tester thinks deserve more attention. ’87 tests passed’ is not a conclusion if the three failures are login, payment and deleting customer data.
If you do not know what to ask a tester to cover, get onto us. Tell us what the product does, the release context and what you are worried about. We can identify the risk areas, recommend the testing approach and, if you want, help you put it into practice.