If you’ve spent any amount of time around software development, you’ve probably heard the terms bug and defect used interchangeably. For all practical purposes, they’re the same thing. Some companies prefer one term over the other, but they both describe the same idea: something isn’t working the way it was intended to.
That sounds simple enough, but one thing I’ve learned over the years is that not every unexpected behavior is actually a bug.
Sometimes the application is behaving exactly the way it was designed, even if users don’t like the behavior. Sometimes the requirement changed and no one updated the documentation. Sometimes a feature request gets reported as a defect because someone expected the application to do something it was never designed to do.
That’s one of the reasons QA spends so much time understanding requirements before we ever start testing. It’s difficult to say something is broken if you don’t know how it was supposed to work in the first place.
A bug can affect a lot of different things. Maybe a button doesn’t work anymore. Maybe a user can’t log in. Maybe data isn’t being saved correctly. Maybe the application crashes under certain conditions. Sometimes the issue is obvious, and sometimes it’s something the user may never notice unless they’re looking very closely.
Not every bug carries the same level of importance, either. A typo on a marketing page is technically a bug. So is exposing another customer’s personal information. Both should be fixed, but they clearly don’t have the same impact on the business or the customer. That’s one of the reasons prioritization is such an important part of software development.
Finding bugs is only part of the job, though.
Whenever someone reports something as broken, the first thing I want to know is whether I can reproduce it. If I can’t make it happen myself, it’s going to be very difficult for a developer to fix it. That usually means asking questions. What browser/device were they using? Was it happening to every customer or just one? Did it happen every time or only once? Were they following a specific workflow? The more information I can gather, the easier it becomes to narrow down what’s actually happening.
Once I can reliably reproduce the issue, I’ll usually spend a little more time exploring it before logging the bug. If someone tells me it only happens in Chrome, I’ll probably check another browser too. If they say it only affects one user, I’ll try another account. I’m not trying to solve the problem myself—I’m trying to understand the scope of the problem so the bug report is as useful as possible.
A bug report isn’t just a way to tell a developer that something is broken. It’s communication. The better you understand the problem before logging it, the easier it is for everyone else on the team to understand, prioritize, and fix it.
I’ll go into what makes a good bug report in another article, because that’s a topic all by itself. Knowing how to communicate a bug is just as important as finding it in the first place.
