Since the first piece of computer software was created, there have been defects. We have came a long way since those days, but defects are still prevalent throughout every application. They are reported by testers or end users, and eventually make their way back to the software developers that created them. Or did they?
One thing I have observed over the past few years is the fact that almost all defects make their way back to software developers, but developers aren’t always the culprits. To make sense of this, you can categorize types of defects. I have noticed there are three different types of defects that seem quite common, Functional, Procedural, and Conceptual.
Functional defects are traditional bugs. I do XYZ, expect A but get B. Software developers are the culprit, and the right person to be fixing the defect (and hopefully using automated testing to prevent it from ever happening again).
Procedural defects stem from bad processes, which may look very similar to I do XYZ, expect A but get B. The reason they got B instead of A is rooted in the fact that a process wasn’t followed. For example, a new feature is introduced that changes how a user creates a widget. The documentation is never updated however, because the sticky note fell off the task board. Oops! To the user, this is a defect, but in all reality, the root cause a process problem.
Conceptual defects are the nastiest ones. These are the defects that stem from requirements, usability, or just bad features. Often parts of an application need to be rethought, removed, and vastly improved to resolve these issues. What do these issues look like?
A user can’t create a new widget. They can’t create the new widget because they haven’t met all the criteria to create new widget (but the criteria isn’t easily understood).
Why is it important to understand these categories? Because software developers can only really solve functional defects, but they often deal with procedural or conceptual defects daily. Being a software development manager, I see this all the time.
Functional defacts fall on the software developers.
Procedural defects fall on whoever is playing the role of project manager for a team.
Conceptual defects fall on whoever is playing the role of product owner/manager for the team.
It is important to have a system in place that can handle all types of defects, not just functional. Otherwise frustration will set in on your developers.