How We Test: A Bug Report and Test Case Example.

A good bug report lets a developer reproduce the problem in two minutes without sending the tester a single follow-up question. A good test case lets anyone on the team walk through a scenario the same way and get a comparable result. These are the two basic things that website testing rests on, and they show whether QA is really working or just "clicking around".

In this article we show our approach: the structure of a bug report, the structure of a test case, examples based on a checkout scenario and how we assess severity. All the examples below are illustrative, made up for explanation, and do not belong to any specific client.

Why standardize bug reports

Bad bug reports cost more than they seem. The phrase "payment doesn't work on mobile" starts a chain: the developer asks which device, the tester answers the next day, the developer cannot reproduce it, marks it "cannot reproduce", the ticket is closed, and the bug stays in production.

A standard format gives three things:

• speed: the developer sees at once what to do and does not spend the morning on an interrogation;
• comparability: ten bugs in the same structure are easy to sort by impact;
• memory: half a year later you can find what has already broken and add a regression test.

That is why in our website testing every bug in the report has the same form and a video.

Anatomy of a bug report

Here are the fields we always fill in.

Title

The title answers three questions: where, what, under what conditions. Compare:

• Bad: "Cart doesn't work".
• Good: "Cart: after deleting an item the coupon stays and the discount is calculated from the old total".

The title should be clear without opening the ticket, because in the list the developer sees only that.

Environment

Without the environment a bug may be impossible to reproduce. We record:

• the URL and the build version or deployment date;
• the device and OS (iPhone 13, iOS 17.5; Windows 11);
• the browser and version;
• the user role (guest, logged in, administrator);
• the test data (which product, which coupon, which payment method).

Steps to reproduce

A numbered list, each step one action. Not "place an order" but specific clicks. The steps should let an unfamiliar person reproduce the bug without guessing.

Expected and actual result

These are two separate lines. The expected result is based on requirements or logic ("after an item is deleted the discount is recalculated"), and the actual one describes what happened. That way the developer sees the gap at once. If the expected behavior contradicts the documentation, state the source.

Severity and priority

These are different concepts, and they are mixed up most often.

A bug with a typo in the logo on the home page has low severity but may have high priority. A bug that breaks only on Internet Explorer 11 may have high severity but zero priority, because there is no traffic from that browser.

Our severity scale:

• S1 (critical): blocks the main flow, loss of money or data. Example: payment does not go through.
• S2 (high): the main flow works but with a noticeable distortion. Example: a wrong discount amount.
• S3 (medium): there is a workaround. Example: the filter resets when going back.
• S4 (low): cosmetics, small UI details.

Evidence

A screenshot with the problem highlighted, a screen recording (almost mandatory for dynamic bugs), and console and network logs if available. A video saves dozens of messages in the thread. For mobile bugs it helps if the recording shows the device indicators.

A bug report example

Below is a typical bug we find in stores. The product and numbers are invented for illustration.

BUG-017. Cart: after deleting an item the coupon stays and the discount is calculated from the old total

Severity: S2. Priority: P1. Status: new.

Environment: staging, build of 2026-10-01, Chrome 129 / Windows 11 and Safari / iPhone 13 (iOS 17.5). Role: guest.

Preconditions: the catalog has product A (UAH 1,000) and product B (UAH 500). Coupon SALE10 is active (10% off orders from UAH 1,200).

Steps:

1. Add product A and product B to the cart (total UAH 1,500).
2. Apply coupon SALE10. Total: UAH 1,350.
3. Remove product A from the cart.
4. Look at the total.

Expected result: product B for UAH 500 remains. The coupon does not apply (minimum UAH 1,200), the total is UAH 500, and the user sees a message that the coupon was cancelled.

Actual result: the total is UAH 450, the coupon stays applied. At checkout the amount is UAH 450.

Reproducibility: 3 of 3 attempts. Evidence: video bug-017.mp4, a screenshot of the cart.

Note: a similar bug is possible when changing the product quantity with the "minus" button.

Notice the details: preconditions are described (otherwise the developer will not find the right coupon), there is a note about a neighboring scenario, and reproducibility is given as a number. This is not bureaucracy; it saves the time of two people.

Common mistakes in bug reports

• Several bugs in one ticket. The developer fixes one and closes the ticket. One bug, one ticket.
• Opinion instead of fact. "Search works terribly." Fact: "search for the word 'jacket' returns 0 results although there are 14 products."
• No expected result. Without it a ticket becomes a matter of taste.
• A bug in someone else's environment. Check that the problem is not a browser extension or the cache before writing the report.
• A ticket closed without verification. "Fixed" should mean "QA repeated the steps and confirmed".

Anatomy of a test case

A bug report records a problem that has been found, while a test case describes exactly what we check before any problems are found. It is a tool for repeatability: the same scenario can be run before every release.

Test case fields:

A test case example

CHK-004. Guest checkout with card payment (positive scenario)

Priority: high (part of the smoke suite).

Preconditions: the product is in stock, the payment provider is in sandbox mode, the user is not logged in.

Steps:

1. Open the product page, add it to the cart.
2. Go to the cart, click "Checkout".
3. Fill in the contact details (name, phone, email).
4. Choose Nova Poshta delivery: city, branch.
5. Choose card payment, click "Confirm".
6. Enter the test card on the payment system page.

Expected result: after step 6 the "Thank you" page opens, the order number matches the confirmation email, the order status in the admin panel is "paid", and the product stock decreased by 1.

Exactly this kind of case goes into our smoke suite: a short list of a dozen scenarios that are run after every deployment in 15–20 minutes. If even one fails, the release stops.

Positive, negative and boundary cases

For every feature we write at least three groups of cases. Take the "Phone" field at checkout:

• Positive: +380501234567 is accepted.
• Negative: letters, an empty field, a number without a country code, an SQL-like string (' OR 1=1 --) do not break the form and do not reach the database as code.
• Boundary: 9 digits, 10, 13, 14; leading spaces; pasting a number with parentheses and hyphens.

Most real bugs live in the negative and boundary scenarios, because a developer by default checks what is supposed to work.

From test case to result: what our process looks like

1. Requirements analysis. We read the spec, the mockups and the site itself, looking for ambiguities. Questions to the client at this stage cost less than bugs.
2. Test plan. We record what we test, what we do not, on which devices, in which browsers and in what time.
3. Test cases. We write them or take them from our ecommerce checklist (150+ items) and adapt them to the project.
4. Execution. We walk through the scenarios and record the result. In parallel we do exploratory testing: free-form scenarios outside the list, where the most interesting bugs are often found.
5. Bug reports. Every bug is written up immediately using the template, with a video.
6. Report. A summary: what was checked, what was found, the distribution by severity, and a "ready to release or not" recommendation.
7. Retest. After fixes we verify every fixed bug and run regression around it.

A separate word about regression. Fixing one bug often breaks neighboring functionality, so we do not limit ourselves to checking the fix itself. If a scenario is key, it is worth moving into an automated test: we wrote about when that is justified in the article on manual vs automated testing.

Need a report like this for your site? We test manually, record every bug using the template with a video, and prioritize by impact on money. Learn about website testing.

How we prioritize what we find

After testing, the report holds dozens of bugs, and the budget for fixes is limited. So we sort them not in the order found but by impact on money and trust. A simple approach that works in practice:

1. First everything that blocks purchase: cart, checkout, payment, delivery.
2. Then bugs that corrupt data: wrong amounts, duplicate orders, lost emails.
3. Then problems that push the customer away: slow pages, a broken mobile version, confusing form errors.
4. Last, cosmetics and small inaccuracies.

That way the client sees at once where to start and can fix the 20% of bugs that cause 80% of the problems.

Tools: what we need and what we do not

You do not need an expensive system to do quality testing. For small teams the following is enough:

• A bug tracker: Jira, Linear, GitHub Issues or even Trello. The main thing is that the ticket template is the same.
• Test cases: a spreadsheet (Google Sheets) or a TestRail-like tool. For 30–60 cases a spreadsheet is enough.
• Screen recording: the built-in recording in macOS and iOS, Android; OBS or Loom for desktop.
• An inspector: DevTools (the Console and Network tabs) for logs and requests.
• Emulators and real devices: DevTools emulation is useful, but mobile bugs with Safari and the keyboard are better checked on real iPhones and Android phones.

A useful habit: in the ticket template make the "Environment" and "Expected result" fields mandatory. They filter out about half of bad reports before they ever reach a developer.

How to judge the quality of a QA report

If you order testing and want to know whether you received quality work, check:

• whether every bug has steps, an expected and actual result, and evidence;
• whether there is a breakdown by severity rather than just a long list;
• whether environments are stated (devices, browsers, build version);
• whether there is a list of what was not checked, and why;
• whether there is a conclusion: is the product ready for release or not.

A report without the last item is incomplete. Testing exists to help make a decision, not to create a quantity of tickets. For what exactly we check in a store, see the 60-point checklist, and for one of the most painful groups of bugs, the article on lost orders at checkout.

Summary

A bug report and a test case are not a formality but a way to make testing predictable. A bug report should answer "what, where, how to reproduce, how bad is it", and a test case "what and how do we check in every release". If you do not have them, start with two things: a single ticket template and a smoke suite of 10 scenarios.

If you want to see what this looks like on your project, there is a free express check in 48 hours, and a full ecommerce QA audit costs from UAH 6,000.

Want to start with an express check? Send the site address in the brief, and within 48 hours we will return 10–15 key problems with video. Send the brief.