What is a bug?
When searching for the definition of a bug (picture showing the first computer bug in history - it was a moth), you can find so many definitions as there are encyclopaedias, but they all sound something like this one from Techweb:
A persistent error in software or hardware. If the bug is in software, it can be corrected by changing the program. If the bug is in hardware, new circuits have to be designed.
A persistent error in software or hardware. Then it's the question of error. What is that? This is taken from Wikipedia:
Error refers to a difference between actual behaviour or measurement and the norms or expectations for the behaviour or measurement.
The key to bugs in the user perspective is the word Expectations. What you can expect. Users classify something as a bug when it doesn't meet their expectations. But how does the developer or programmer conceive it? Well, if it doesn't work as the spec (in the form of documentation, use cases, storyboards or what ever means of communication is used), then it's a bug. It doesn't work as they thought they designed it or should have designed it.
For me, working with requirements, I meet these both types of "bugs" but I also meet process bugs. People who do things they ought not do, for legal or other reasons. Loop holes, we call them. You're not supposed to be able to change customer on a case which we've already billed. And the system was not designed for that, and suddenly the data looks weird. If we upgrade the system and remove that possibility, the user's think that this is a bug: we can't change customer anymore!
So, what is important in these cases is understanding why the users use those loop holes. It's not that they are evil: they are most of the times trying to do their work. And that is why it's important to sit down and listen to these users to figure out the real use cases and how they are going to work. Sometimes their work method is the bug: they are doing stuff that is not legal and then they need to be informed. And in those cases there are bugs in the processes. So, bugs don't have to be in the software or the hardware (if you don't include humans in that definition).
But most of the time they are performing their duties but no one has bothered to find out their needs and included their needed functionality into their systems.
Labels: usability
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home