Sounds like a simple question doesn't it? But is it?
Roll back a few years when I was a small way into my testing career and I would have been able to confidently answer the question very simply. A bug is anything that isn't quite right with the software. My job as a tester was to squeeze out every last obscure, difficult to find issue with the product - in fact We used to have a competition to see who could find the most way out, corner case bug. Much kudos was obtained by being able to find the unfindable.
In those days when asked at interviews what makes me want to test, I used to pridefully give the response that I have come to fear and hate, "I love breaking things!" This was fairly indicative of the software industry at the time - teams of testers would take receipt of a dev complete product then try their damndest to break it.
But thinking evolves, and thinking around test has evolved a fair way from what it used to be.
Agile integrates test along side development, widens the responsibility of test away from just the tester to the team and focuses the priority towards features and delivery. What Agile also does is restrict the time we have with a feature to an iteration (or part of an iteration depending on how quick it can be coded). This dramatically reduces the time one can spend attempting to 'break' a feature. We need to apply some smart thinking to our testing. Who tests what and where, more unit testing, less automated UI testing - targeted manual testing - all things that help to make sure we are not only testing, but testing smartly. Even with better approaches and distributed testing streams, we still have to start looking at our scope.
Which brings me back to my original question - what is a bug? I am reminded of the old saying - if a tree falls in a forest but no one is around to hear it, does it make any noise? Not wanting to get too philosophical on the matter, but our bug exploration should be a bit like that. We can spend a great deal of time trying to find those hard to find elusive bugs, but what is the point? They are hard to find and elusive (on the whole) for a reason, because they are rare, unlikely scenarios that a customer is extremely unlikely to come accross. We have taken the focus away from the typical, common usage scenarios in order to find the killer bug. Our focus has potentially sacrificed the many for the sake of the few (or none). So if a bug is unlikely to ever be found by a customer, is it really a bug?
Agile, in combination with the 'skilling up' of our test engineers has provoked a shift in the way we approach ensuing a product is tested - no longer is the 'play with it for a week and try and break it' a good enough plan for testing - its unreproducible, (meaning a cumulative investment in effort release after release to achieve the same testing), it's ineffective and promotes the obscure bug mentality. We now have to engage with our customers to learn how the product is used, we have to know how it is developed to identify areas of risk, we have to understand what tests are being written by others so we can test a bit smarter and we have to put all these things together to ensure that our customers are getting a product that will work really well for them in the vast majority of their use cases.
Is it a bit risky? after all a bug is a bug is a bug! well, yes, it is a risk - but testing 101 teaches that you will never find all the bugs and all shipped software has a number of bugs waiting to be uncovered by customers. QA is all about managing the risks appropriately - so is it really worth chasing the elusive?
What then is a bug? a bug to me is something that causes, (or will cause) our users to have issues using our software.
