Why the Title Matters More Than the Rest of the Report
A good bug title = where it happened + what you did + what went wrong + the condition that triggers it. Say all four in one line and a developer can reproduce it without asking you anything. That is the entire difference between a good title and a bad one. Below are 40 side-by-side examples across seven scenarios — login, registration, payments, mobile, APIs, performance, and UI — so you can rewrite your own bugs against them.
Developers scan titles first, every single time. A vague title means either an extra round of questions or the ticket gets skipped entirely. Worse, a bad title can't be rescued by a great environment block — nobody opens a ticket called "button broken."
A title passes or fails on four things: is it specific (names the component or page), is it observable (states facts, not "doesn't work"), does it carry conditions (browser, device, account type, timing), and does it let a reader judge scope (a total outage or an edge case).
The 4-Part Bug Title Formula
[Component/Page] + [Action] + [Unexpected result] + [Condition]
How to fill each slot:
- Component: checkout page / login modal / order list /
POST /api/orders - Action: click, submit, upload, switch tab, scan
- Unexpected result: no response, 500 returned, value off by one digit, state not synced, text overlapping
- Condition: Chrome 120, iOS 17.2, width <390px, enterprise accounts only, after a network timeout
Sentence case, component first, no priority tags. That's the convention most teams settle on — and consistency matters more than which convention you pick.
1. Login and Accounts (7 Examples)
| Weak title | Strong title |
|---|---|
| Login button doesn't work | Clicking "Sign in" in Chrome 120 does nothing; console throws TypeError: login is not a function |
| Password reset email not received | No reset email after clicking "Forgot password" with a Gmail address (checked spam after 30 minutes) |
| Wrong redirect after login | Standard user lands on /admin instead of /dashboard after login; reproducible since v5.3 |
| CAPTCHA keeps failing | Valid CAPTCHA still rejected with "Invalid code" — only in private/incognito windows |
| Account locked out | Three wrong passwords lock the account permanently, but the message says "try again in 24 hours" |
| Session not invalidated | Logging in on a second device does not invalidate the first session, which stays fully usable |
| SSO login fails | SSO callback returns "Invalid signature" starting after the IdP certificate rotation |
Takeaway: for login bugs, the condition field (browser, account type, incognito) decides whether anyone can reproduce it. Don't skip it.
2. Registration and Forms (7 Examples)
| Weak title | Strong title |
|---|---|
| Can't register | Signup rejects email addresses containing "+" (e.g. user+test@x.com) with "Invalid email format" |
| Phone validation broken | A complete 11-digit number still triggers "Enter an 11-digit phone number" |
| Password strength hint is wrong | An 8-character password that already contains digits still shows "must include a number" |
| Dropdown won't select | Country dropdown cannot be selected with arrow keys after filtering by typing 3 characters |
| Form submits twice | Pressing Enter in the signup form submits twice, creating two duplicate user records |
| Required field not enforced | Signup succeeds without ticking "I agree to the Terms" and the account is created anyway |
| Wrong timezone default | Timezone defaults to UTC+0, so users in UTC+8 must change it manually on every signup |
Takeaway: replace description with concrete input values. One real string beats ten sentences of "input doesn't work."
3. Payments and Checkout (7 Examples)
| Weak title | Strong title |
|---|---|
| Payment fails | Order total of $129.99 shows as $1,299.99 (extra digit) at checkout, and the payment page inherits the wrong amount |
| Coupon not working | Expired coupon still shows as "valid"; applying it returns a 500 and empties the cart |
| Cart count not updating | Header cart badge still shows "1" after removing the last item, until the page is refreshed |
| Charged twice | Retrying payment after a network timeout charges the same order twice (order #10231) |
| Invoice details not saved | Company invoice details are cleared when going back a step and returning to checkout |
| Refund status out of sync | Order still shows "Paid" in the customer view after the refund was issued (order #10388) |
| Missing payment method | Card option is missing at checkout — only for accounts on the legacy billing plan |
Takeaway: for anything involving money or order IDs, put the order number in the title. It cuts triage time in half.
4. Mobile and Responsive (6 Examples)
| Weak title | Strong title |
|---|---|
| Layout broken on mobile | "Add to cart" button overlaps the price text on iPhone 14 (iOS 17.2) below 390px width |
| Page won't scroll | Opening a modal locks page scroll on mobile, and scroll stays locked after the modal closes |
| Input hidden by keyboard | Android Chrome keyboard covers the "Submit" button so it cannot be tapped |
| Landscape layout broken | Nav bar wraps on iPad in landscape (1024×768) and the logo overlaps the menu |
| Images not loading | Product hero image missing on Safari iOS 16; console returns 403 (expired CDN signature) |
| Tap target too small | Mobile pagination buttons have a 12×12px tap target, below the 44px accessibility minimum |
Takeaway: on mobile, "mobile" is not a condition. Write the exact model, OS version, and viewport width.
5. Data, APIs, and Permissions (6 Examples)
| Weak title | Strong title |
|---|---|
| Export fails | Exporting more than 10,000 orders returns 504; batching the export works |
| Wrong timestamps | Report timestamps are 8 hours behind actual time, only for users with timezone Asia/Shanghai |
| Search returns nothing | Searching "iPhone" returns 0 results although 12 matching records exist in the database |
| Duplicate rows when paginating | Order list repeats the last 3 rows of page 1 at the top of page 2 |
| Upload error | PNG uploads above 5MB return 413, but the UI reports "Upload complete" with an empty file |
| Privilege escalation | Read-only role can call DELETE /api/projects/12 and delete a project successfully |
Takeaway: for API bugs, put the HTTP status code, endpoint path, or threshold number in the title. It's half the debugging work done up front.
6. Performance and Loading (3 Examples)
| Weak title | Strong title |
|---|---|
| Page is slow | Homepage LCP is 8.2s on 4G, dominated by 2.1MB of uncompressed JavaScript |
| Memory leak | Memory grows from 120MB to 900MB after switching tabs 20 times, then the tab crashes |
| API is slow | Product list endpoint P95 is 4.8s (baseline 300ms), only during peak sale traffic |
Takeaway: performance bugs need a number and a baseline, otherwise nobody can judge whether it's a defect at all.
7. Copy and UI Details (4 Examples)
| Weak title | Strong title |
|---|---|
| Typo on page | "Recieve order confirmation" should be "Receive order confirmation" at checkout |
| Inconsistent icons | Two of the four icons on the settings page are line style, two are filled style |
| Dark mode unreadable | Input text is #333 on a dark background in dark mode, effectively invisible |
| Useless error message | Failed upload shows only "Operation failed", with no cause and no retry guidance |
Takeaway: for copy and UI bugs, write "what it says → what it should say." Lowest review cost of any bug type.
7 Habits That Make Titles Worse
How Different Roles Should Write Titles
| Role | How to write |
|---|---|
| QA / tester | Full 4-part formula, all conditions filled in (browser, device, account, network) |
| Support or ops escalating | User-visible symptom + reproducible path + screenshot; skip the cause if unknown and mark it "pending dev confirmation" |
| UAT reviewer | Anchor to the acceptance criterion: "Fails AC-3: order status not updated within 5 seconds" |
| Product manager | Describe the user-visible impact for prioritisation, but don't replace the technical symptom |
When a Title Gets Translated
| Original-language title | English title |
|---|---|
| 结算页删除最后一件商品后购物车角标未更新 | Cart badge not updated after removing the last item on checkout |
| Android Chrome 键盘遮挡提交按钮，无法点击 | Android Chrome keyboard covers the Submit button, making it untappable |
| 只读角色可删除项目（越权） | Read-only role can delete projects (privilege escalation) |
Three rules when a title crosses languages: keep component names in the original language if they're proper nouns, translate the observable result literally, and never translate log messages or error codes. A translated stack trace is an unreproducible bug.
FAQ
How long should a bug title be? Keep it under roughly 60 characters or 10 words so it isn't truncated in list views. If it doesn't fit, either the core symptom hasn't been extracted yet, or it's actually two bugs.
Should the title include priority or severity? No. Priority is a separate field that changes with scheduling. Once it changes, the title is wrong — and it pollutes search.
Can I write a guess in the title if I don't know the cause? You can write "possibly caused by X", but never as a settled conclusion. Explain the reasoning in the body, or you'll send triage down the wrong path.
Should one bug on multiple browsers be multiple tickets? Title the core symptom and put environment differences in the environment or notes field. Split only when the fix paths genuinely differ — for example, separate iOS and Android code paths.
Title case or sentence case? Either works, but match your existing backlog. With no legacy constraint, sentence case reads better and is easier to scan.
You Still Write the Title; Everything Else Can Be Automatic
To be clear: BugCapturer does not write your title — that takes your own judgement about what you saw. But the tedious, easily-forgotten fields can fill themselves in:
- Automatic technical context: URL, browser, OS, screen resolution, and viewport size are captured for you, so the conditions in the title never have to be copied by hand.
- Diagnostic data: error-level console logs and failed network requests (HTTP ≥ 400) are collected, with sensitive parameters (tokens, passwords, API keys) automatically redacted.
- Annotated screenshots: drag to select the problem area and add arrows, boxes, and text, so "where it's wrong" is fixed in the image.
- Screen recording: record the current tab and trim the clip, so developers receive a 12-second video they can verify against.
- One-click share or sync: generate a share link that external collaborators can open without registering, or push the report into Feishu Bitable or a generic webhook.
That way you only have to get that one title line right, and the tool fills in the rest.
Downloadable Checklist
Paste this next to your monitor and check it before you hit submit:
- Does it name the component or page?
- Does it state an observable fact instead of "doesn't work"?
- Does it include conditions (browser / device / account / network / width)?
- Does it carry a verifiable number (status code, order ID, amount, duration, threshold)?
- Does it describe exactly one symptom?
- Are priority and any unverified guess removed?
- Is it under roughly 60 characters / 10 words?
Pass all seven and your titles will get triaged ahead of 90% of the backlog.
Further reading: Bug report template (full field list and a copy-paste template) · How to report bugs effectively · Test case template with examples · Bug report format · How to write steps to reproduce