Form questions

Beta feedback questions that sort bugs, gaps and keepers

Ask 10 to 14 per beta round, with the bug section repeated for each issue. Never skip the steps to reproduce, the keep or cut decision on the new features, and the device and version. Without steps a bug cannot be fixed, and without the version it cannot be matched to a build.

Beta feedback has three jobs: find the bugs, find what is missing, and find out which new features are worth keeping. These twenty two questions keep those apart, with a structured bug report, a feature rating grid and a direct keep or cut question for each new feature.

The questions

About you and your setup

  1. Which device did you test on?DropdownRequired

    List the devices the beta supports, plus Other.

  2. Which build or version were you on?Short textRequired

    Tell testers where to find it. A bug without a build number is half a bug.

  3. How much did you use the beta this week?Single choice

    Not at all, under an hour, one to five hours, more than five hours.

  4. What did you mostly use it for?Long text

Bugs

  1. One line summary of the problemShort text

    Write it the way you would search for it later.

  2. Steps to reproduceTable

    A table with Step and What you did; a classic table shows a fixed number of rows, so set enough for a typical bug.

  3. What you expected to happenLong text

  4. What actually happenedLong text

  5. How bad is it?Single choice

    Blocks me completely, annoying but I can work around it, cosmetic.

  6. Does it happen every time?Single choice

  7. Screenshot or screen capture imageFile upload

    Images or PDF only.

New features

  1. How useful is each new feature?Rating gridRequired

    Rows are the new features in this beta; columns not useful to very useful, plus did not try.

  2. Which new feature would you miss most if it disappeared?Dropdown

  3. Keep, change or cut: the feature you used mostSingle choiceRequired

    Keep as it is, keep but change it, cut it.

  4. If you said change it, what would you change?Long text

  5. Was anything confusing the first time you used it?Long text

Gaps and overall

  1. What did you expect the beta to do that it does not?Long text

  2. Overall, how ready does this feel for everyone?Single choice

    Not ready, nearly ready, ready.

  3. How satisfied are you with the beta overall?Single choice

    1 to 5.

  4. Would you keep using it if the beta ended today?Single choice

  5. Anything else the team should know?Long text

  6. Can the team contact you to follow up?Single choice

Which questions to make required

Four are required: device, build, the feature rating grid and the keep, change or cut question. The bug section is optional on purpose, because not every tester finds one, and a required bug summary produces invented bugs. On the linked bug report form, which is built for one bug at a time, the summary, steps and expectations are required instead.

The form built from these questions

A static copy of the finished form, from its own example page.

Report a bug in Ledgerly

Reports go straight to the engineering board. Include steps; a report we cannot reproduce goes to the back of the queue.
#What you did
1
2
3
4
5
6
One action per row, in order, starting from a fresh login. Row numbers are the step numbers. Six rows is a budget, not a target; three good rows reproduce most bugs.

The whole screen, including the URL bar. Blur anything private first.

Up to 3 files, images or PDF. Plain text logs are not accepted as files; paste them below.

Three ways to change this bank

For a closed alpha with a handful of testers, drop the satisfaction questions and run a short call after each round instead. For a public beta with thousands of users, keep only the device, the keep or cut question and one open box, and collect bugs through a separate bug report form so the survey stays short. For hardware, add serial number, firmware version and the conditions of use, such as temperature or terrain. Whatever the product, keep the keep, change or cut question in every round, so the team can see whether changes made between builds won testers over.

Questions people ask

How often should beta testers be surveyed?

Once per build or beta round, usually every one to two weeks, and keep a separate bug form open all the time. A survey at the end of each round asks about the features in that build while testers remember them. Surveying more often than that tires a small group fast.

What makes a beta bug report useful?

Steps someone else can follow, what the tester expected, what happened instead, the device and the build number, and a screenshot. A table of steps works better than a paragraph because it forces one action per row. Severity helps the team decide what to fix before launch.

Should beta testers rate every feature?

Only the new or changed features in that build, plus a did not try column. Rating the whole product every round blurs the signal. A short grid of three to six features tells the team which ones landed and which ones nobody found, and the did not try column is a finding in itself.

Why ask keep, change or cut?

Because a satisfaction score does not tell a team what to do. A direct choice between keeping, changing and cutting a feature produces a decision the product team can act on. It also gives testers permission to say a feature should go, which they rarely volunteer.

How many beta testers are enough?

For finding usability problems, small numbers go a long way; for finding rare bugs across devices, more testers and devices help. Many teams run a small closed beta first, then a larger open one. The survey questions stay the same; what changes is how much detail each tester is asked for.

What should happen to beta feedback after each round?

Triage bugs by severity and reproducibility, tally the keep, change or cut answers for each feature, and list the top gaps. Share a short summary with testers, including what was fixed. Testers who see their reports acted on keep testing carefully, and the next round produces better reports.

Should beta feedback be anonymous?

Usually not. The team often needs to ask a tester for more detail or a log file. Ask for permission to follow up as a separate question, and only contact testers who agree. Keep feedback forms limited to invited testers so outsiders cannot submit.

Build this form in about a minute

The button opens the form generator with this form already described. Change the wording to match your own, generate, then edit any field.

Create a form with OneCraft

Other question banks

Pricing survey questions including the Van Westendorp four

Pricing survey questions ask what people spend now, what they would consider too cheap and too expensive, which plan they would choose and which features they would pay for. These twenty questions centre on the four Van Westendorp price sensitivity questions, asked in a fixed order after people know what the product does.

Product feedback survey questions for in app and email

A product feedback survey asks how satisfied users are, which features they use and how important each one is, what is missing, how easy the product is and whether it is good value. These twenty two questions work in an in app prompt or an email, with the role question near the end so answers can be split by user type.

Customer interview questions for discovery calls

Customer interview questions for discovery should ask about what people did recently, not what they would do in the future, because past behaviour is the best evidence of a real problem. These twenty three questions run in five stages and are captured by the interviewer in a form, so every call produces notes in the same shape.

On writing the questions themselves, read How to pilot a survey before you send it. For everything the builder can do, see the form maker. Step by step: Create a form from scratch with AI, then View, export and manage your responses.

Sources

Written and checked by the OneCraft team. Last checked .