Reproducible software bug intake
Bug report form for reproducible software issues
Guide reporters to supply the affected component and build, runtime context, shortest repeatable path, expected result, actual result and evidence—without asking them to guess priority or assign the fix.
Sign in to inspect this populated view, then install the App with sample data to test the connected records, decisions and dashboards.
What the reporter supplies—and what triage decides
A good bug report form improves the odds that another person can reproduce the problem. It should collect observable facts first, then let the triage team decide severity, priority, ownership and target release.
- Reporter fields separated from triage fields
- Mobile-safe form with file evidence
- Returned-for-information path instead of silent rejection
Reporter field guide
Collect the minimum complete reproduction packet
Every field should help someone repeat, classify or investigate the problem.
- 01
Clear summary
Describe the visible failure and affected action.
- 02
Component and build
Select the product surface and exact version when known.
- 03
Environment
Record device, browser, operating system, tenant or configuration.
- 04
Steps to reproduce
List the shortest repeatable sequence in order.
- 05
Expected vs actual
State the intended result separately from what occurred.
- 06
Evidence and impact
Attach useful proof and explain who cannot continue.
After submission
Return incomplete reports without losing the conversation
The form is only the start; triage needs a visible next step for each outcome.
Check reproducibility
Confirm the environment and repeat the supplied path.
Ask for missing context
Return the report with a specific question and keep the same record.
Merge duplicates
Link the new report to the canonical issue instead of deleting it.
Accept and assign
Record severity, priority, owner and target release.
Write reports people can act on
Replace vague claims with observable differences
A short report can still be complete when it separates context, action and result.
| Weak report | Actionable report | Why it is better |
|---|---|---|
| Checkout broken | Payment confirmation times out after the 3DS return in Web 4.28.0 | Names the action, failure and build. |
| Sync duplicates | Tapping sync twice after reconnect creates two rows with the same local ID | Provides a repeatable trigger and observable result. |
| Export wrong | Scheduled CSV omits two saved custom columns in Reporting 12.2 | Identifies mode, data difference and release. |
Questions and boundaries
Bug report form questions
Answers for deciding which fields belong in intake and which belong to triage.
Should reporters choose severity and priority?
Usually no. Reporters can describe business impact and urgency, while the triage team applies shared severity and priority definitions.
How long should reproduction steps be?
Use the shortest sequence another person can repeat. Include setup only when it changes the outcome, and note how often intermittent behavior occurs.
What if the reporter does not know the build?
Allow “not yet known,” but collect enough environment context for triage to identify it. Do not block useful reports because one technical field is unavailable.
Can the form be used on mobile?
Yes. Reporters can record the affected component, environment, steps to reproduce and evidence from a phone, then submit the report to the same triage queue as desktop users.
Improve the first handoff
Start with a report another person can reproduce
Open the sample form on desktop or mobile, then adapt the fields and routing to your product.