Kuidas koguda veateateid, mida arendaja mõistab

Every agency gets the same email. Subject line: “Problem”. Body: “The site isn’t working, please fix.” Attached, a screenshot of a browser window with the address bar cropped off. The developer replies with three questions, the client answers one of them, and three days later it turns out the whole thing was about a different page in a different browser.

This is not laziness on the client’s side. It is that we are asking a person to write down information they cannot see and do not know exists. No client knows there is red text in the console. So a good bug report is not one where the client tried harder — it is one where the right things were collected without them having to try at all.

The anatomy of a report

Whatever tool you use, a developer needs the answers to six questions. Miss one and the correspondence starts.

• What did you do? Concrete steps, not a description. “Opened the cart, pressed Pay, chose Swedbank” is steps. “Tried to buy something” is not.
• What did you expect? It sounds redundant, and it is exactly where half of all “bugs” turn out to be a misunderstanding about how the feature was meant to work.
• What happened instead? The error text verbatim, not paraphrased. “An error occurred” and “Payment declined” are two different tickets.
• Where? The exact URL. Not “in the shop” but the whole address including query parameters — a filter or a locale prefix in the URL is very often the detail that causes the bug.
• With what? Browser and version, operating system, screen width. Half of all layout bugs exist only in one width band or one browser.
• Does it repeat? Once, or every time. A one-off and a reliably reproducible failure are two different tickets with two different priorities.

On top of that there is the context a client cannot write down because they cannot see it: browser console output, failed network requests, the session’s language, the timezone. That layer is usually where the answer is.

Why email will never collect this

An email thread is a synchronous process pretending to be an asynchronous one. Every clarifying question costs a day, because the client answers when they have a moment. Three questions, one week. Email also keeps no structure: six months later nobody will find which message held the version that actually worked.

Writing “please submit a detailed report” into the client handbook does not work either. Someone who has just hit a bug is annoyed and wants to report it in thirty seconds. If reporting takes longer than that, they will either say nothing or write one sentence. Full context arrives reliably in one situation: when it is collected automatically, at the moment the person presses the button.

What can be collected automatically

Here is an honest account of what our widget captures — and what it does not. When a visitor submits feedback, the description travels with:

• The page URL exactly as it stood in the address bar, query parameters included.
• A screenshot the reporter can annotate before sending — circle the problem, blur personal data.
• Browser, version, operating system and device type. Where the browser supports it, the version comes from Client Hints rather than being guessed out of the User-Agent string.
• Screen and window size, orientation, colour depth, timezone offset and the browser’s language list.
• Console output and JavaScript errors. The hooks are installed at the very start of page load, so errors that happened before the person touched anything are captured too.
• Failed network requests — method, URL, status code and duration. That one line is usually what decides whether the fault is in the front end or on the server.
• Optionally a screen recording and a voice note, for the cases where showing the steps is faster than writing them.

Now the limits, because they matter just as much. The console and network buffer holds the last 120 entries, so a page that has been spraying warnings for minutes no longer contains the earliest ones. We only see what happens in the browser: server logs, database queries and background jobs stay on your side. And the widget does not capture form field contents — if the bug depends on particular input, that still has to be described in words.

Ending the ping-pong in practice

Automatic context solves the technical half. The human half is solved by three agreements, best made before the project starts.

One place. If the client may report by email, WhatsApp and phone, you have three disconnected lists and no overall picture. Agree that a report which is not in the system is not a report — then make reporting so easy that no alternative is needed. When the number of reporters is unlimited, there is no reason to leave anyone out either: the tester, the content editor and the client’s marketing person can all report directly.

One ticket, one problem. A message listing seven issues cannot be prioritised and cannot be closed. Seven short tickets are better.

Visible status. The client has to see what is happening to a report, otherwise they will ask again through another channel and the ping-pong restarts. If reports land automatically in the same task system the team already works in, the status updates itself instead of waiting for a reminder.

Where to start

If bugs currently arrive by email, you do not have to rebuild the whole process. One change is enough: put a reporting button on the staging site and ask the client to use only that for the next acceptance round. After a week, count how many clarifying questions you had to ask. That number usually answers the question of whether the tool was worth it.