If you are curious about testing apps as work, the useful thing is a clear picture of what the work involves before you apply — not a pitch.
So here is what being a Bugfed tester actually looks like day to day.
What you actually do
You get assigned to a test run for a specific app. Each run comes with a brief — the flows the client wants covered, anything they already know is broken, and any specific conditions to try.
Then you use the app on your own device and report what goes wrong.
That is genuinely it, but the gap between doing it well and doing it badly is very wide. Doing it well means:
- Working through the brief deliberately instead of tapping around for two minutes
- Trying the awkward paths — cancelling halfway, denying a permission, losing connectivity, going back a screen
- Noticing things that are not crashes: a confusing label, a button that is hard to hit, text that overflows, a delay that feels wrong
- Writing up what you found so a developer who has never spoken to you can reproduce it
What you need
A real device you own and use. A phone, tablet, or computer. It does not need to be new — older and mid-range devices are genuinely valuable, because they surface performance and memory problems that flagship devices hide. A three-year-old budget Android is an asset, not a disadvantage.
A reliable internet connection, and the ability to install apps from a store link, a test track, or a direct file.
Clear written communication. Reports are the entire output. A bug nobody can reproduce from your description is a bug that does not get fixed, which means your work produced nothing.
Attention to detail and a bit of stubbornness. The best testers are the ones who notice something felt slightly wrong and then spend ten minutes working out exactly when it happens.
Follow-through. Some runs — Google Play closed tests in particular — require staying opted in and engaged for a fixed period, often 14 days. Signing up and disappearing on day three breaks the client's run. Reliability is the single most important quality.
What a good report looks like
This is the skill of the job, so it is worth being concrete. A weak report:
Login doesn't work sometimes
A strong report:
Login: app hangs on "Signing in" when connection drops mid-request Device: Redmi Note 12, Android 13, app build 2.4.1 1. Open the app while logged out 2. Enter valid credentials 3. Turn on airplane mode immediately after tapping "Sign in" 4. Turn airplane mode back off after ~10 seconds Expected: an error message, or a retry, or a successful login. Actual: the spinner runs indefinitely. Force-closing and reopening is the only way out. Reproduced 3 out of 3 times. [screenshot attached]
Same bug. The first version gets closed as unreproducible. The second gets fixed.
The pattern to internalise: device and build, numbered steps from a known starting point, what you expected, what actually happened, how often, and evidence.
Devices that are in demand
Coverage needs vary by run, but a few things are consistently useful:
- Older and mid-range Android devices, especially 4GB RAM and below
- Manufacturer skins beyond stock Android — different OEMs manage background processes very differently
- Older OS versions, since these are where deprecated behaviour surfaces
- Tablets and foldables, which fewer testers have
- Devices in a range of regions, because network conditions and locale handling differ substantially
If you have an unusual or older device, that makes you more useful, not less.
Applying
Testers are vetted before being matched to runs, so there is an application and approval step rather than instant access.
[Apply to become a tester →](https://tester.bugfed.com/signup)
The application asks about your devices, your OS versions, and your region — the information needed to match you to runs that suit what you actually own.
Being good at it
A few things that separate testers who get matched to more runs:
Read the brief properly. Clients list known issues for a reason. Reporting something already flagged as known is wasted effort on both sides.
Report the small things. If something felt slow, confusing, or off, say so even if you are not certain it is a bug. Uncertainty is fine — flag it as uncertain. The instinct that something is wrong is often the most valuable signal in a whole run.
Do not pad. Ten weak reports are worth less than two good ones and take longer for everyone to process.
Try to narrow intermittent bugs. "Happens on cellular but not wifi" turns an unfixable ticket into a solvable one. That kind of narrowing is genuinely skilled work.
Be reliable on multi-day runs. Stay opted in. Open the app across the full period rather than once on day one — some bugs only appear after a few days of real use.
If that sounds like something you would be good at, the application is the place to start.
[Apply to become a tester →](https://tester.bugfed.com/signup)