I am a Bug 1

Learnings from I AM A BUG

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. The priority of any given bug may actually change if the business or technical
context changes.
a. A bug that was important last week may not be important this week.
b. If the customers have decided that they no longer need a particular feature, a
bug that had a high priority the day before may not even be relevant
anymore.
c. Those who decide bug priority and severity should be acutely aware of the
business context.
d. They should know who the stakeholders are, who the customers are, what the
technical constraints are, what the design drivers are, and so forth.
e. Then they should use this knowledge to alter their view of new bugs if
necessary, and to update their view on old bugs.

3. A lot of bugs in a program can aggravate users and even make the program
unusable, even if each bug has a low severity on its own.

4. A low severity bug with an easy workaround might generate many support calls if it
affects lots of users.

5. In medical software, a grammatical error can have more devastating effects than a
system crash. If medical software crashes, the doctor won’t use the diagnosis, and
no one will be hurt. But a grammatical error, such as confusing the past tense with
the present tense, could mean the difference between life and death if it affects how
a patient’s medical history is read.

6. 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!

7. A friendly bug is a bug that does not stop users from enjoying and benefiting from
the software. Just because it doesn't conform to the requirements doesn't mean it's
bad! Sometimes a feature that enhances users' experiences with the software may
be a bug because it does not conform to the requirements. Other friendly bugs can
be little nuances in the program that weren't intended but don't bother users.

8. The AVT-710 patient record software had lots of bugs, but people could avoid them.
Even with these bugs, it was a reliable product with a zero field reported software
defect rate.

Copyrights - Parimala Shankaraiah – http://curioustester.blogspot.com

I am a Bug 2

9. Sometimes we find bugs a long time after people start to use the program (Sleeping
bugs).At the time the software was written the bug was there, but it did not become
apparent until later when the context of the software changed.

10. A classic example is Visio 97. It was originally designed at a time when hard disk
space was much smaller than it is now. But try installing Visio 97 on a newer
computer with a lot of disk space, and the installer says that there is not enough disk
space for Visio to be installed. Why? Because Visio 97 uses 32-bit arithmetic to
calculate free disk space, and that worked fine at the time it was made, but newer
computers have such a large amount of hard drive space that it cannot be calculated
in 32 bits! Due to round off error and truncation, the calculation is bogus. This bug
was dormant for years and was exposed by the evolution of the technical constraints
over time.

11. When a sleeping bug wakes up it can cause backward compatibility headaches if
users have become used to the bug and depend on it being there. A classic example
is the margin calculation in Microsoft Word, which was incorrect in older versions.
When Microsoft fixed the bug, all files from the previous versions had slightly skewed
margins in the new, fixed version.

12. When we test computer programs we make a "test plan". A "test plan" is like a net
to catch bugs. Some "test plans" only catch BIG BIG bugs! Some "test plan" nets
work best to catch small bugs.

13. There are test suites called FAST, where FAST stands for Functional Acceptance
Simple Tests. This tests every capability of the system once with normal data to gain
some confidence that the system can handle normal inputs, but it doesn't guarantee
that the system can handle anything else.

14. When bugs can be fixed in a simple, straightforward manner, we feel only a minor
irritation.

15. 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.

16. There are specific techniques for finding specific kinds of bugs. A good example is
self-verifying data checks. For specified inputs, the software can be checked against
a testing oracle. This is an excellent way to find data integrity bugs.

17. A technique for finding buffer overflow bugs may be very good at finding buffer
overflow bugs, but they would be useless for finding calculation errors. Bugs much
worse than buffer overflows would just walk right by! Similarly, checking for data
integrity bugs through self-verification techniques is not time or cost effective if
there are a lot of user interface bugs or business logic bugs precluding the testing
from reaching the data.

18. 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

Copyrights - Parimala Shankaraiah – http://curioustester.blogspot.com

I am a Bug 3

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." This
sounds attractive at first, but these types of tools require a very large amount of
programming and don't really solve any problems. They also make maintaining tests
a nightmare. Tool vendors may also claim that a requirements tracking tool "will
reduce costs". But the tool itself will not save money; what will save money is having
the discipline to manage requirements.

19. This is the pesticide paradox: if the same testing technique is used over and over
again, the bugs that the test technique targets will disappear, but other bugs will find
a way to survive. Don't rely on only one technique or tool.

20. Sometimes the solution is worse than the problem. The solution to a bug may create
(or reveal) other strange behaviours in the system. Or the bug may be fixed
perfectly on the functional level, but quality factors like performance, reliability,
availability, maintainability and so on are compromised.

21. We try new ways to make our program - Trying new techniques and new ways to
work around problems is a double-edged sword. For instance, to avoid having to
develop a high-risk piece of software, sometimes people will trust third-party
middleware. This avoids the development problem entirely, but results in a lot of
integration problems with other software.

22. When we are not sure of what to do, we can sit back and wait until things calm
down.
a. Sometimes the best thing to do is step back from the project and look at the
big picture.
b. Instead of hunkering down and coding while there are still lingering concerns,
take the time to understand the requirements and identify helpful
technologies, tools, skills, and processes. Otherwise you can get stuck solving
the wrong problem!
c. There are times when a project shouldn't even be undertaken. Once I helped
formally inspect a development plan against its requirements, and so many
discrepancies were found that the project was cancelled. That project
shouldn't have been started in the first place, and it wouldn't have been if
they had taken the time to understand the problem.

23. We use many ways to get rid of bugs. We can scare them away. They don't die, but
they get out of the way!
a. Sometimes it's a good thing to expose as many bugs as you can to be aware
of their existence.
b. You might not be able to isolate them or fix them until later, if ever, but you
know they're in there somewhere. For example, some companies try a
dramatic approach called a Bug Bash before the release of a product.
Employees work over the weekend to expose all the bugs by whatever means

Copyrights - Parimala Shankaraiah – http://curioustester.blogspot.com

I am a Bug 4

they can think of. The bugs probably won't be fixed or even isolated before
the product's release, but the company will know the bugs are there.

24. Assertions test whether a program is in the state it should be during execution. E.g.,
whether a file is opened before it is written.
a. If the assertion is violated when it should not be, the developer knows there
is a bug.
b. For unit testing and sometimes early system testing, assertions can be very
useful for finding bugs quickly.
c. However, assertions do not make business decisions; if they are violated,
they stop the program's execution.
d. For later system testing, this means that a minor bug could halt testing until
it is fixed, so assertions shouldn't be present by that stage.
e. Assertions are even less appropriate for release in a commercial system.

25. Frogs like bugs! People, at work, think positively about bugs. We like to find bugs!

26. 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.

27. Bugs try to avoid frogs - Naturally, when we try to fix a bug, it tries to avoid us!

28. There are several different ways in which bugs can camouflage themselves.
a. One way is to hide in plain sight. Take, for instance, a bug that brings up an
error message before login. During testing, the testers learn to ignore it to log
in to the system, and almost unconsciously click it away. This way the testers
never really treat it as a bug, and grow so used to it that it is eventually
ignored.
b. A second way for a bug to be camouflaged is when it is cancelled out by
another bug. For example, in a database system, a bug that returns an
incorrect query could be cancelled out by a bug that reports queries
incorrectly.
c. A third way is for a big bug to hide a little bug (or lots of little bugs), such as
a catastrophic failure that obscures a user interface error because the
problem area can't be reached. This is why it's important to retest a system

Copyrights - Parimala Shankaraiah – http://curioustester.blogspot.com

I am a Bug 5

once a bug has been fixed to be sure that no other bugs have been
unearthed.

29. Some bugs are best caught by system monitoring. For these bugs, monitoring agents
like BoundsChecker can be set up to watch the system and flag bad system
behaviors, including inappropriate access to system resources and memory leakages.
There are other bugs that can be found though inexplicit testing. To find browser
compatibility bugs, just test the software as normal while varying the browser and
the browser compatibility bugs will pop out.

30. Getting lots of frogs can help get rid of lots of bugs.
a. Once we decided to get lots of people to help us find and correct all the bugs.
b. Too many frogs in the same place are a big problem too!!! But that didn't help
because we got mixed up and confused.

31. Bringing in more testers to work on a project can be a nightmare. Any training needs
will result in a temporary dip in productivity, the mythical man month will come into
play, and management requirements will increase to the point where there may be
no productivity gains at all.

32. How did we catch it? Is it important? Can it hurt us?

33. If we use the program in a different way, we will avoid some bugs completely. -
Sometimes it's better to provide a workaround for a bug instead of fixing it. This is
especially true if there's no time for regression testing, because fixing a bug could
reveal more bugs.

34. Quick patches don't solve problems. Fix it right the first time!

35. 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.

36. Regression testing is used to make sure the bug is really gone and no others have
sprung up in its place.

37. The most important question we ask ourselves is whether we have finished our work
- find that the fundamental question of software engineering is "How do you know
you’re finished?"
a. Many developers start development without knowing the answer to this
question. Some answers to the question are better than others.
Unfortunately, some developers consider themselves finished when they have
to go home. They catapult the code over to the next phase in development,
and I find that this results in poor quality. It is far better to answer the
fundamental question using information gained from requirement
management, configuration management, and testing. The answer to the
fundamental question may involve ensuring some particular degree of code

Copyrights - Parimala Shankaraiah – http://curioustester.blogspot.com

I am a Bug 6

coverage, some static analysis, or a quality factor like usability, reliability, or

maintainability.
b. But in order to ask the fundamental question, the exit criteria must be
accurately defined and widely understood. For example, unit testing answers
the question "Am I finished implementing this unit of code? Is it ready to be
passed along to someone else?" If unit testing is sloppy, it may be and often
is because the developer doesn’t understand what the purpose of the unit of
code is. Thus, when the developer uses unit testing to decide if he is finished
with the unit of code, he may be making the decision based on a false
assumption of what it means to be finished.
c. 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.

38. We know our job is done when the bugs that are left are the ones we can live with at
least for now! So stop testing and get some sleep folks!

Copyrights - Parimala Shankaraiah – http://curioustester.blogspot.com