Reference
My website has a bug - what do I do.
Why detail matters.
Tomislav Simnett
3 min read
To a developer, ‘it doesn’t work’ is an all too common dialogue between someone looking over the site - usually someone non-technical, and definitely someone who hasn’t read up on reporting bugs effectively.
“The site doesn’t work.” “What do you mean, the site doesn’t work?” “It just doesn’t work.” “So what is it doing that it shouldn’t be doing?” “When I go to the site, I can’t do X.” “But when I go to the site, I can do X.”
Testing after development
After development comes testing, and during testing, bug reports are made. If the bug reports are unclear in any way, then it takes more time to fix them, because it takes more time to decipher their real meaning. So what this article is about is understanding the core elements of a good bug report, and why “It doesn’t work” is bad.
What a development bug report should look like
From the perspective of a developer, a good bug report consists of a specific set of things that must always be there in order to be able to replicate it. Without the ability to replicate a bug, the chances of it being fixed are very slim. The above article by Simon Tatham, a very well regarded developer, of PuTTy fame, is probably one of the best groundings I’ve seen for writing good bug reports for software, and it extends to web applications and sites too. The first of these things is a concise but clear summary of the bug. One line is enough - just something that describes the issue, eg. “Firefox 3.0.3 prevents upload of multiple files in new messages”. That’s a good summary that with some additional information as described below is the formative part of a good report.
Detailing the bug
The concept of “Show me how to show myself” is crucial here. What’s needed is a step by step set of directions by which you came to see the bug. The developer may well not have used the application in this way and didn’t expect it to be, but users will always do the unexpected! If the issue is a display issue, take a screenshot, and include the whole window, not just a bit of it. If it’s a browser issue, and this happens a lot on the web, the developer needs to know which browser the issue happens in. If the same issue happens in every browser, one screenshot will do, but a comment to that effect is absolutely necessary. There are also some key facts that should be included with any and all bug reports: Operating System, Browser, Browser version, URL on which the error occurs. Some other useful pieces of information, depending on the bug report are: Flash version (or that it’s not installed), JavaScript status (on / off). If you think there are any more, there probably are, so feel free to comment on this article.
Key takeaways
So, to conclude, we need a good summary (usually marked down in a subject field if you’re using a bug reporting system), a set of facts about the machine you’re seeing the issue on, a clear set of instructions on how to reproduce the bug, any additional information the developer might need to reproduce the bug, and if you can, a screenshot or set of screenshots to show the developer the problem you’re seeing.
If you would like further information on the development process, our team of software developers are more than happy to help. Get in touch today to learn more.
How much capacity is your business leaving behind?
Use the calculator to estimate what slow processes, manual work and disconnected systems could really be costing you.
More posts.
View all
Tech
AI can write the code. Your business still needs an engineer
AI can now write a lot of the code we used to pay developers to write. That doesn’t make software engineering irrelevant. It makes the bit that was always more important much harder to ignore: understanding what should be built in the first place.
Vibe coding can turn your assumptions into working software incredibly quickly. But if the assumption is wrong, you’ve simply built the wrong thing faster. Good engineering starts before the app, CRM or automation. It starts by understanding how the business actually works, where people add judgement, and which parts of the process shouldn’t exist at all.
Tomislav Simnett
11 min read
Business
Four interruptions, two lost hours and the process your people shouldn’t be driving
Four interruptions can wipe nearly two hours from the useful part of a working day, and that’s before you count the interruption itself. Add long manual processes, routine human error, rework and stress, and you get a working environment where good people spend too much time recovering, correcting and chasing.
The answer isn’t to tell people to focus harder. It’s to design a better system, one that drives the process, preserves context, moves routine work automatically and only interrupts people when their judgement is genuinely needed.
Tomislav Simnett
10 min read
Business
The approval takes five minutes. The waiting costs far more.
A five-minute approval can leave work waiting for days. Once a quote, purchase, job or invoice misses its slot, the delay spreads into the rest of the process.
People switch tasks, schedules move, customers wait and cash arrives later. The decision itself may be quick, but the queue around it can cost far more than anyone realises.
Tomislav Simnett
9 min read