Get paid to test apps and websites: a practical tester’s guide
You can get paid to test apps and websites without a background in software. Companies need ordinary people on ordinary phones and laptops to try a sign-up flow, a checkout or a new feature and say what happened. The pay is per test, and the testers who earn most are not the most technical ones but the ones who follow the script and write reports a developer can act on. This guide covers what the work involves, the equipment you need, a bug report template and why tests get rejected.
What app and website testers actually do
Most paid testing tasks fall into three shapes. Knowing which one you are looking at tells you what the employer wants back.
| Test type | What you do | What they want back |
|---|---|---|
| Functional test | Walk through a defined flow (register, pay, upload) and check that each step works | Pass or fail per step, bug reports for failures |
| First-impression or usability test | Use the product as a new user would, often thinking out loud | Honest observations: what confused you, what you liked, where you would give up |
| Compatibility check | Open a page or app on a specific device or browser | Screenshots of layout problems, notes on anything that does not load |
Website testing jobs are often shorter and done in a desktop or mobile browser; app tests usually involve installing from Google Play or the App Store and last longer. Both reward the same skill: noticing what went wrong and explaining it so someone else can see it too. For current categories and typical requirements, see app testing tasks and website testing tasks.
Devices and setup
You do not need a test lab. You do need to know exactly what you are testing on.
- One phone you know well. Android or iPhone. Many tests specify one or the other, so note the model and OS version in your phone's settings.
- A desktop or laptop browser for website tests. Keep one browser up to date and know its version (usually under Help or About).
- A screen recorder. Both Android and iOS have one built in; desktop operating systems include screenshot and recording tools as well.
- A stable connection. A test that fails because your Wi-Fi dropped is not a bug report, and wastes your time.
A routine for every test
Use the same routine for every test and your reports get faster and more reliable:
- Check the requirements. Confirm the device, operating system, browser and country the test asks for before reserving it.
- Prepare your device. Update the OS, free some storage, charge the battery, turn on Do Not Disturb and start the screen recorder if one is required.
- Follow the test script in order. Do each step as written. Note the time and what you see whenever something breaks or confuses you.
- Reproduce anything that breaks. Try a failing step again once or twice so you can describe exactly how to trigger it.
- Write the report. Use a clear structure: summary, steps to reproduce, expected result, actual result, device details and evidence.
- Attach evidence and submit. Add the screenshots or recording the task asks for, check they show what you describe, then submit.
Budget your time against the task's time limit. If the estimate is 15 minutes, reserve the slot when you have 25 free: installs and slow sign-up emails eat more time than expected.
How to write a bug report that gets approved
A bug report has one job: let a developer who was not there see the same problem. Vague reports ("login doesn't work") are the top reason testing submissions are sent back for revision. Use this template:
Bug report template
- Summary: one line, what broke and where. "Checkout: Pay button stays grey after entering a valid card."
- Steps to reproduce: numbered, starting from a known point. 1. Open the app logged out. 2. Add any item to the cart. 3. Tap Checkout…
- Expected result: what should happen. "Pay button becomes active."
- Actual result: what did happen, including any error text word for word.
- Frequency: every time, sometimes (2 out of 3 tries), once.
- Environment: device model, OS version, app version or browser version, Wi-Fi or mobile data.
- Evidence: screenshot or recording, with the moment of failure visible.
A worked example
Weak: "Signup broken on my phone." Strong: "Sign-up: after entering a valid email and tapping Continue, the screen goes blank for ~5 seconds and returns to step 1. Happens 3 out of 3 tries. Pixel 7, Android 14, app v2.3.1, Wi-Fi. Recording attached, failure at 0:42." The second report takes one extra minute and is the kind employers approve and come back for.
Usability feedback is different
When a task asks for opinions, be specific and honest rather than positive. "I didn't understand that 'Spaces' meant folders until the third screen" is more useful than "nice design". Employers pay for real reactions; do not invent problems or praise to look thorough.
Screen recordings and screenshots
- Start recording before step one, so the reviewer sees the whole path, not just the error.
- Narrate or annotate if the task asks. Otherwise keep it silent and put timestamps in your written report.
- Hide personal data. Close notifications and do not show passwords, full card numbers or private messages. Use test data if the task provides it.
- Keep files reasonable. Trim long idle parts; a 2-minute clip that shows the bug beats 20 minutes of scrolling.
- Screenshots must be yours and new. Reusing a screenshot from an earlier task, or editing one, is treated as fake proof.
The most common reasons tests get rejected
| Reason | How to avoid it |
|---|---|
| Wrong device or OS | Check requirements before reserving; state your device in every report |
| Skipped steps | Follow the script in order, even steps that seem pointless |
| Missing or unclear evidence | Show the failure on screen; match the proof type exactly |
| Vague report | Use the template: steps, expected, actual, environment |
| Generic feedback | Give concrete observations tied to specific screens |
| Out-of-scope bugs | Report issues in the area being tested; mention others briefly at the end |
If you did follow the instructions and still got rejected, you can open a dispute within 7 days and attach your evidence. Tasklify compares the task's published instructions with your proof and decides, normally within 48 hours. If an employer asks for a revision instead, fix what they asked and resubmit before the deadline.
Getting access to better-paid tests
Longer tests with recordings and written reports tend to pay more per task, and employers often restrict them to workers with a strong approval rate or a minimum number of completed tasks. The path there is unglamorous: do shorter tests well, keep your approval rate high, and move up through the levels. With Plus, $1+ tasks appear an hour earlier, which helps with popular tests that fill quickly.
Frequently asked questions
Do I need technical skills to get paid to test apps?
No. Most tests are designed for ordinary users. What matters is following the test steps exactly and describing problems clearly: what you did, what you expected and what happened.
What equipment do I need for website testing jobs?
A computer or phone with an up-to-date browser, a stable internet connection and a way to take screenshots or record the screen. Some tests require a specific device or browser and say so.
How long does an app test take?
Most take between 10 and 30 minutes. The task shows an estimated time and a time limit; reserve it only when you have enough time to finish, including installation.
Can I use an emulator or VPN for testing tasks?
No. Emulators and VPNs used to fake your device or location are prohibited, and submissions made that way are rejected and can lead to an account ban.
What if I find no bugs?
That is a valid result. Report that each step passed, include the required evidence and any usability observations. Do not invent bugs to look thorough.