Although bugs have been part of software development since computers were first programmed, not all bugs are created equal. Most people think software bugs are just programming errors – a failure or flaw in a program that produces undesired or incorrect results – but this isn’t strictly true. There are many reasons for software bugs and they have different ways of appearing…
Type 1
First you have the case where the person who specifies the program talks to the customer, but the customer may not have thought through exactly what they want. If we simplify the analogy down to colours, the customer says he wants it in blue, but actually he needed it in pink. The developer presents the program in blue, but is then told by the customer that he wanted it in pink!
Type 2
In a second scenario, the person who is writing the spec may miscommunicate with the customer, or may not have talked to the customer properly to understand the requirement. In other words, the customer may have said ‘pink’ but what was heard was ‘blue’, which was then written down as part of the spec. As a result, the customer will think the finished program has a bug, but it’s actually an error in specifications.
Type 3
At the next level the person who wrote the spec may miscommunicate with the programmer — the programmer implements exactly what he thought was required, but he hasn’t got it right because he’s misunderstood the instructions.
Type 4
And then finally we actually have a real bug – when the programmer intended to make it “blue” but actually typed “pink” or somehow put “pink” into the code.
So, we have four different stages in the process through which ‘bugs’ can occur. And the difficulty we have is that users tend to think all bugs are like the last case!
In fact, the first three examples are usually referred to as defects – that is, a deviation from the requirements. A defect does not necessarily mean there is a bug in the code (i.e. due to human error); it could be a function that was not implemented, or not defined in the requirements of the software.
So, when we test bespoke software – giving early versions of the software to customers to test – what we’re really doing is asking the customer to check for defects; to see whether we’ve understood their requirements properly, and the requirements testing process.
Navigating through these four different stages can create challenges in software development projects.
Quite often the developer (or the development company — it happens at both levels!) wants to send an early version to the customer to say: “tell me if I’m on the right track.” At this early stage, the program can look rough and buggy, and often it’s not easy explaining to customers that we we’re not looking for a bug report – just a nod to confirm the project is going in the right direction. It means having to explain our intentions in the context of the analogies discussed above.
It goes without saying that before we consider any software system as ‘functionally complete’ and ready to deliver to the customer, it’ll have gone through our own extensive software testing and quality assurance processes to ensure its fit for purpose.
So – when is a bug really a bug? It’s quite an interesting challenge!