Form questions

Bug report questions an engineer can work from

Ask 8 to 12. Six questions reproduce a bug: a one line summary, the steps, what you expected, what actually happened, the browser or app, and how often it happens. Never skip the steps, the expected and actual pair, or the environment, because without them nobody can reproduce it.

A bug report has to give an engineer enough to make the problem happen again on their own machine, without a single follow up message. These questions separate the goal from the steps and the expectation from the result, so a vague it is broken becomes a ticket someone can pick up.

The questions

The problem

  1. One line summaryShort textRequired

    Becomes the ticket title, so cap it at about 120 characters.

  2. Where in the app?Dropdown

  3. What were you trying to get done?Short text

    The goal, not the steps. It often exposes a workaround or a misunderstanding before anyone investigates.

  4. When did you first notice it?Date

  5. Did this work for you before?Single choice

    Yes, it used to work; no, it has never worked; not sure. A yes points at a recent release.

Reproducing it

  1. Steps to reproduceTableRequired

    One column, one step per row, so the order survives.

  2. What you expectedLong textRequired

  3. What actually happenedLong textRequired

  4. Does it happen every time?Single choice

    Every time, most times, sometimes, once.

  5. Approximate time it happened, with timezoneShort text

  6. Can you still make it happen now?Single choice

  7. Error message, pasted exactlyLong text

    Pasted text can be searched; a picture of an error cannot. Logs go here too.

Environment

  1. Browser or appDropdownRequired

  2. Browser or app versionShort text

  3. Device and operating systemShort text

  4. Does it still happen in a private window with extensions turned off?Single choice

    Yes, no, did not try. Rules out a blocker extension in one question.

  5. What kind of connection were you on?Single choice

    Office network, home broadband, mobile data, VPN, not sure.

  6. ScreenshotPhoto upload

    A photo field takes a single image. Use file upload when more than one screen matters.

  7. Exports or capturesFile upload

    File upload accepts images and PDF only, so a screen recording has to arrive as a link.

  8. Link to a screen recording, if you made oneShort text

Impact and contact

  1. How bad is it?Single choice

    I cannot use the app, a feature is broken, there is a workaround, cosmetic.

  2. How many people on your team does it affect?Single choice

  3. What deadline, if any, is this blocking?Short text

  4. Account emailShort textRequired

    Short text, since the email component renders nothing on a published classic form.

  5. May support contact you for more detail?Single choice

Which questions to make required

Six questions are required: the summary, the steps, the expected and actual results, the browser or app, and the account email. A report missing any of the first five cannot be reproduced, and one without the account cannot be looked up in the logs or answered. Severity stays optional here on purpose, because reporters tend to rate their own bug highest and triage should set it.

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 an internal QA team, add the build number, the test case reference and the environment (staging or production), and make severity required, because trained testers apply the scale consistently. Drop the connection and extension questions, which testers control anyway. For a feature request form, replace the reproducing section with the problem the person is trying to solve, how they work around it today, how often they hit it, and how much time the workaround costs, then keep the impact questions as they are. For a website content error report, cut it to five: the page address, what is wrong (a typo, a broken link, out of date information, an accessibility barrier), what it should say, a screenshot, and an optional email for a reply.

Questions people ask

Why ask what the user was trying to do as well as the steps?

Because the steps describe the path and the goal explains it. Someone who clicked export three times may have been trying to print, and the real fix is a missing print option rather than a broken export. Reading the goal first also helps support answer quickly when the report turns out to be a question.

Should a bug report form ask whether it worked before?

Yes. A yes answer points engineers at a recent release and narrows the search from the whole codebase to the last few changes. A no suggests a gap or an edge case that was never handled. Keep a not sure option, since many reporters only noticed the problem today and genuinely do not know.

How do you collect a screen recording when uploads accept only images and PDF?

Ask for a link. The file upload field allows images and PDF, and nothing else, so a video has to be shared through the reporter's own storage or a recording tool and pasted into a short text question. A screenshot plus written steps is usually enough, so keep the recording link optional.

What makes a good one line summary?

It names the place, the action and the failure in one sentence, such as invoice PDF download returns a blank page in Safari. Words like broken, urgent or does not work say nothing an engineer can search for. A short example in the question label shows reporters the pattern better than a rule does.

How do the steps look when the responses are exported?

The CSV export has one column per question, and a table question arrives as a single column holding the filled rows as a JSON list. That keeps the steps in order, and a short script can split it into numbered lines before the report is pasted into a tracker.

Should customers and internal testers use the same bug report form?

Usually not. Customers need plain language, a severity scale written as sentences and no jargon about builds or environments. Testers need build numbers, test case references and a required severity. Two forms that export to the same tracker keep both groups answering in their own terms without confusing either.

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

Customer effort score questions

Effort is what a customer remembers about a support experience long after they have forgotten who helped them. These questions measure the whole journey from first message to fix, rather than rating the last person in the chain.

Support ticket feedback questions

A ticket survey competes with the moment a customer finally gets their day back, so it earns about ninety seconds. These questions put the rating and the resolved check in the first two screens and treat everything after that as a bonus.

Product review questions

A review form gets a useful review by breaking the job into parts somebody can answer one at a time, instead of handing them an empty box under the word review. Split praise from warning and the same customer writes twice as much.

On writing the questions themselves, read How to collect file uploads with a form. For everything the builder can do, see the form maker. Step by step: Create a form with AI, then View, export and manage your responses.

Sources

Written and checked by the OneCraft team. Last checked .