How to write a test task that gets useful feedback

"Check out my app and let me know what you think." It's the most common request in indie dev land, and it reliably gets you the least useful answer: "Looks good!"

That isn't the tester's fault. You gave them nothing to do, so they poked around for a minute, found nothing broken, and left. A test task fixes this. On TestSwap, every app has one: a single concrete thing you ask testers to do, in 200 characters or fewer. Here's how to write one that gets you feedback you can use.

Why "check out my app" fails

No goal. The tester doesn't know what success looks like, so they can't tell you where it failed.
No starting point. They land on a home page and wander.
No scope. "Everything" is too big to review, so they review the logo.
Nothing to compare to. If you never said what you expected, you can't see where reality differed.

The anatomy of a good test task

One goal. Pick the single most important thing a new user must be able to do. Not three things. One.
About 10 minutes. Reviewers are doing you a favor. A task that takes ten minutes gets finished; a task that takes an hour gets skipped.
Starts from a URL. Say where to begin: the web address, the TestFlight link or the Play Store link. Don't make them hunt.
Says what "done" looks like. "You should see your first report" is a finish line. Without one, nobody knows when to stop or whether they succeeded.
Names the part you're unsure about. This is the secret ingredient. If you suspect the pricing page is confusing, say so. Testers will look hard at the spot you point to.

You don't need all five every time. 200 characters is tight, so choose the ones that matter most.

Before and after: six examples

Each "after" below fits within the 200-character limit.

1. A habit tracker

Before: Try my habit tracker and tell me what you think.

After:Create a habit, mark it done for today, then find your 7-day streak. Was it obvious where to look? I'm unsure about the streak screen.

2. An invoicing tool

Before: Check out my invoice app.

After:Make an invoice for a fake client and download the PDF. Note anything that made you hesitate. I worry the tax field is confusing.

3. A language flashcard app

Before: Test the onboarding and give feedback.

After:Sign up and finish your first 5-card lesson without asking for help. Where did you slow down? Is the progress bar clear?

4. A developer API dashboard

Before: Try the dashboard and see if it makes sense.

After:Using the demo login, create an API key and copy the curl example. Did the example work as written? Tell me about any missing step.

5. A mobile game

Before: Play my game and tell me if it's fun.

After:Play the first three levels. When did you first feel confused or bored? Did the controls feel right on your phone?

6. A landing page with a waitlist

Before: What do you think of my site?

After:Read the page for 30 seconds, then tell me in one sentence what the product does. Then join the waitlist. Did anything stop you?

Notice the pattern: an action, an observable finish, and a question aimed at a specific worry. None of them say "give feedback". The question does that.

Demo credentials: be careful

If your app needs a login, don't make testers sign up if you can avoid it. Each app on TestSwap can include optional demo credentials, which are shown only to signed-in users. Some tips:

Create a throwaway demo account just for testers, with sample data in it.
Never put a real password, or any password you use elsewhere, in the credentials field.
Don't attach payment methods, real customer data or admin rights to the demo account.
Reset the demo data now and then, since testers may change or delete things.
If your task is about signup itself, skip the demo account and let testers sign up for real.

For reviewers: what a useful review looks like

If you're on the other side, writing a review, a few habits make the difference between a 👍 and a 👎. Remember that on TestSwap a 👎 takes back the credit you earned, so effort pays.

What you tried. Say what you actually did, step by step. It proves you did the task.
Where you hesitated. The moment you paused, re-read something or tapped the wrong thing is the most valuable data point you have.
One concrete improvement. Pick the change that would help most and describe it. "Make the button bigger" beats "improve the design."
Bugs go in the private field. A review has two public parts (what the UX was like, what to improve) and an optional private bug notes box that only the maker sees. Put crashes, broken links and error text there, with the device and steps to reproduce.

A short example

For the habit tracker task above, a useful review could read:

UX: I created "Read 10 pages" and checked it off. That was easy. I had to scroll to find the streak and only noticed it because the task told me to look. I expected it on the home screen.
Improve: Show the streak count next to the habit name instead of on a separate screen.
Private bug notes: iPhone, Safari. Marking a habit done twice quickly adds two entries.

A maker can act on every line of that.