“It’s a bug!”, or is it? Working in bespoke software development, this is something I hear daily. Be it from the client, developers, business analysts, product owners, or dare I say it…testers, the term is thrown around like the empty promises of a politician in an election year. But are we really defining defects correctly and if not, is that detrimental to the software development process? As we strive to produce high quality software, we should also be implementing high quality processes and that includes knowing exactly what we are talking about.
What's in a bug?
The formal definition of a bug is, “A flaw in a software component or system that can cause the component or system to fail to perform its required function e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system.” For me this can be broken down a little more simply starting with an ‘error’:
- To err is human; we all make mistakes, in this case the error may cause the software to perform incorrectly.
- A ‘flaw’ is the manifestation of the error in the software (this is identified as the ‘bug’ during software testing).
- Finally, ‘failure’ is the event caused by the bug (which was caused by the error) where the software deviates from its intended purpose.
There are several types of bugs, but it’s important to note that these are errors in the software. Therefore, the standard testing types provide a broad description of the issue you are looking for e.g. functional issues; where the software does not behave as expected or, regression issues; where a previously working function no longer does so correctly.
What's not a bug?
There are others types of defects such as ‘error handling’ which is not necessarily a specific test type but should certainly be incorporated into the planned testing. These sorts of errors are found via testing the robustness of the software, often called ‘negative’ or ‘destructive’ testing where the user deliberately misuses the software to measure the ability to contain and handle the unexpected inputs and provide the user with relevant information required to understand or overcome the issue. It’s also very important to remember that when you are testing you are representing the intended users of the software and need to be vigilant around the user experience (UX), including the interface, syntax, clarity, simplicity and anything that negatively impacts the user journey.
There are also types of issue or ‘error’ that are commonly mislabelled as bugs. Let’s look at a few, starting with ‘design defects’. Sometimes an issue or gap in the design may not be identified until later in the process such as during testing. It would be unfair to call this a ‘bug’ when the code is correct and has delivered to the specification provided. How about ‘improvements’? Again, the requirements may have been delivered to the letter and all acceptance criteria met, but the delivery may not meet expectations or someone’s interpretation, or simply could be better.
Bug investigators
Then there are some issues that may or may not be bugs, but will need more investigation before they can be classified. For instance, incorrect data may cause bugs in the software but it’s necessary to understand the root cause i.e. how did the data get there, was it down to the code or another part of the process? Could it happen again? Is the test and therefore the defect, valid?
Why is it important to differentiate? Politically, it might be easier to just accept all of the above as bugs and fix them via the code. In the past, I’ve worked with project managers who took that limited approach, mostly to make their life with the client a little easier! However, it would be short-sighted and the drawbacks are insurmountable. To improve quality, you need to understand the root causes of the issues and address them, whether that be identifying weaknesses in the processes, supporting and improving understanding and expectations or increasing skill levels for a project role. ‘Fixing’ all these issues as ‘bugs’ would be just the same as plastering over the cracks - unnecessary rework that isn’t part of the agreement, unstable foundations (code!) based on ill-defined expectations and unhappy stakeholders all-round! Worst of all, the same issues will repeatedly occur, nothing will improve and everyone will continue to be unhappy. Sad times that would lead to a myriad of negative consequences.
Despite all this, it’s just as important to recognise a bug, so never trust a developer when they give you that look and say “it’s not a bug, it’s a feature…!”
