What is a bug in software development? I’ll tell you. If you’re in a hurry you can scroll to the bottom. But, if you’re not, first a little background.
Today I had the pleasure of arguing about what a bug was. For those of you who aren’t in the software business this might be too much detail for you, but there are some good points about some random stuff.
Heres my disclaimer. I am far from being accomplished at having relationships. I get along with people pretty well, but I’m always worried when it comes time to have a disagreement with someone for fear of hurting their feelings. I try to be nice and talk about the issue and not the actions of those involved in the issue. At some point though, I fail. I let my feelings get ahead of my mind and before I know it I’m saying something that completely prevents me from having any influence with the person I’m dealing with.
So, today I got an email that said we should create a bug on the feature that I had added. That’s fine with me. I’m not perfect and I could have accidentally failed to code something so that it didn’t fail. That’s why we have testers. Anyway, as it turns out the thing that they were wanting to call a bug wasn’t a bug. It was an additional feature that they discovered they wanted only after I gave them what they asked for.
Being new to the company I thought twice about whether or not I wanted to challenge the status quo and decided quickly, “Uh… yeah. I do.” So I shot of a fairly short email that said something like, “Are you sure this is a bug? Seems like it’s additional features that you’re asking for now that you’ve seen what you asked for.”
Quickly, another email arrived that brought in the QA manager to discuss the definition of a bug. His definition was way over the top on the side of a QA person. To a person responsible for finding fault with the application, everything that isn’t perfect is, and should be “a bug”, but in this sense, the QA’s bug isn’t always a bug. Sometimes they find a missed feature. Sometimes they find that two requested features conflict in some way. These are both bugs to them. They’re problems with the quality of the application.
So, to clear, QA keeps a list of things that the application could stand to improve. They look at it with a critical eye and judge it worthy or not from every aspect possible.
That list, whatever you want to call the items on it, is not what I’m talking about. What I’m talking about is what happens after those things are found. QA reports them and they can pretty well tell whether or not they’re defects in workmanship of the developer, or something the developer should have thought of but didn’t (also a defect in my opinion). But, when they’re looking at a requested feature, and testing it to determine if it does what it’s supposed to do, and it does, but they notice that as a result of this feature, other things are required that weren’t asked for? That is not a bug. That is a new feature.
So, here’s what a bug is. But, first a few words about the process. We develop software in chunks. We call those iterations (at my current company). Each iteration contains the following parts or activities.
- A list of features are introduced by the product owner
- The development team, product owner, and quality control professional all agree what the stories mean.
- The development team estimates the amount of work required to complete the stories.
- The entire group agree on what features will be included in the iteration.
- The developers code the solutions
- The QA creates a document that says how will test each of those features.
- The product owner “judges” the work on it’s completeness.
Therein lies a hint to what a bug is. But let’s break it down just a bit further first. There is a team here, working to accomplish a common goal. We all want the same thing. We want a quality product that delights the client. We all do! The thing that introduces tension is money. The product owners have a different pile of money than the developers do. QA is also a separate budget. So the team is all aligned toward a common goal, but the business is separating the functions. That’s fine, but by doing that we have to hold our business partners accountable for pulling their weight otherwise we’re paying people out of our budget to do their work! That’s not fair… especially if it cuts into my bonus.
So we have an agreed upon list of things to do. We agreed on what each of those items were. We agreed on how long, (and thereby how much money it would cost) it would take to complete the requested items. At this point folks we have a contract. It’s a contract even if it is just an agreement between people that hopefully have a good relationship with one another. But it is a contract and with good reason for each member of the contract to fully abide by their part of it.
So, what is a bug? A bug is a failure to meet the requirements agreed upon with the quality agreed upon by the team and the company they work for. If the product owner didn’t realize that asking for a feature was a detriment to the product then they didn’t do their job. Let’s put a system together where we can assign bugs to the quality of their work.
That was a rant, but thanks for reading.