I am a Bug is a book written by Robert Sabourin. This is a short book illustrated by his daughter Catherine which explains the software development process using cartoons and live examples from real time projects.
Little Nuggets from the book
1. When a bug is found, we do not ask if the bug is good or bad. We decide if it is important. We guess how much damage it could cause.
2. When we rush too much making new software, our offices and programs can get pretty messed up. We know there will be a lot of bugs!
3. Some bugs have many brothers and sisters (Bug clusters).
4. Bugs much worse than buffer overflows would just walk right by! (Inattentinal Blindness).
5. Some bugs are good friends! (Deferred bugs). A friendly bug is a bug that does not stop users from enjoying and benefiting from the software.
6. If we use the program in a different way, we will avoid some bugs completely (Change in perception).
7. Bugs can be fixed, avoided, or ignored. If a bug won't be fixed, users can be encouraged to use the software in a way that avoids the bug (Workarounds).
8. Sometimes we find bugs a long time after people start to use the program (Sleeping bugs).
9. Salespeople from tool vendors sometimes misrepresent the costs and benefits of tools and their ease of use. For example, they may claim that a test automation tool that can capture actions and play them back will "solve all your problems". They'll say, "Take this tool, and you can write a program that will find all your bugs."
Testers vs. Frogs
1. Frogs like bugs! People, at work, think positively about bugs. We like to find bugs!
2. Frogs eat bugs!
a. When we find bugs we really, really, really like to fix them!!
b. Whether or not a given bug should be fixed depends upon the business context.
c. Just as the frog's stomach can only contain a finite amount of bugs, a development team doesn't usually have the time, effort, and money to fix all of the bugs found in a program.
d. Bug priority and severity need to be established based on a cost/benefit analysis to figure out which bugs are worth fixing. The costs of not fixing a bug can be the damage to a user's computer, the number of support calls generated by a bug, damage to a company's reputation, and so on.
e. Just a few of the potential drawbacks of fixing a bug are the danger of injecting or uncovering more bugs, the developer time and effort spent, and the chance of decreasing adherence to quality goals for availability, performance, etc.
3. Bugs try to avoid frogs - Naturally, when we try to fix a bug, it tries to avoid us!
4. Getting lots of frogs (Crowdsourcing) can help get rid of lots of bugs. Once we decided to get lots of people to help us find and correct all the bugs. but too many frogs in the same place are a big problem too!!! But that didn't help because we got mixed up and confused.
5. How did we catch it? Is it important? Can it hurt us?
6. Quick patches don't solve problems. Fix it right the first time!
7. Think about how the program will be used. The exact same program can be used by many different people in many different ways, and a bug that is a dealbreaker for one user community may be inconsequential to another.
a. This is why I want everyone on a project or specific task within a project to have a common notion about what the answer to the fundamental question is. This way everyone knows what her role in the completion of the task is.
As testers, we are emotionally bound to every single bug that we report to the development. We expect that every bug be fixed in the immediate next build. In reality, it is very hard to fix all the bugs. Any business context demands that a product be released in the quickest time possible, within budget and on schedule. As a result, it is important to realize which bug is important and which is not. Testers are not decision makers, they are information providers. Let the decision makers decide which bug to fix. This book highlights the importance of bugs and the prioritization of fixes for the important bugs. I have documented important points from the book in the ‘Pearls of Wisdom’ section. Do take a look if that helps. Rob Sabourin has been generous to provide a FREE online version of this book on his website Amibug.com.
Happy Reading,
Parimala Shankaraiah
Great post, Parimala!
ReplyDeleteGood review.. I feel there are quite a good number of takeaways from this book and will ensure to read it sometime in the near future. Thanks for giving the heads up :
ReplyDeleteHi Pari,
ReplyDeleteI read the book.... I liked it very much.... What drew my attention was Monkey Testing, Assertions and FAST. FAST similar to our BVT... Liked this book. It is very simple and clear
@Allmas
ReplyDeleteThank you very much.
@Mohan
Atleast for me, This is one of those books that guides testers about how bugs need to be handled by testers, developers, managers, product management teams etc with respect to Business Objectives of the organization.
@Sindhu
I am very glad that you read the book.
Regards,
Parimala Shankaraiah
Hey,
ReplyDeleteBook is awsum!!!
Thanks for sharing
Bugs......... I really like bugs.... but i hate QA team when they release bugs at week ends :)
ReplyDeleteand between thanks for sharing will read it when i find some time...
Tarik
ReplyDeleteI am glad so many people are actually reading the book. This is a MUST read for all testers who are too clingy with the bugs they find(I have been one such tester for a long time now. I am working on it :-)).
Manjunath
What about programmers who release QA builds on Friday evenings? Just kidding.
I think any team(of programmers, testers, doc team and management) should be problem focused rather than person focused. This is an art and a tough one at that.
Look forward to your comments after you read the book,
Regards,
Parimala Shankaraiah