Bug Advocacy

What is a bug ?
What is a bug?

A bug or error in software product is any exception that can

hinder the functionality of either the whole software or part of
it.

A deviation from requirements?

What about missing requirement

Faulty requirements

Unexpected behavior
How to define expectation?
 What is a Bug Life Cycle?

The duration or time span between

When the first time bug is found (New)

and

The bug found is closed successfully (Closed, Rejected,

Postponed or Deferred) is called as Bug Life Cycle.
 Bug Report Life Cycle or Workflow
Bug Reports move through a series of states (life cycle or
workflow) to resolution.
In each non-terminal state a manager or the bug triage
committee specifies who is to move the bug to next state.
Bug tracking system cam implement and automate workflow,
but project team and management support is required to
make the workflow work
Often state transition include a log, status entry or history.

Assigned Closed
Review Open Test

Deferred
Rejected
Reopened
 Status associated with a bug:
New:
When a bug is found for the first time, the software tester
communicates it to his/her Team leader, in order to confirm if that is
a valid bug. After getting confirmation, the tester logs that bug and
the status New is assigned to the bug.

Assigned:
After the bug is reported as New, it comes to the Development
Team which verifies if the bug is valid. If it is valid, Development
leader assigns it to a developer to fix it and a status Assigned is
assigned to it.

Open:
Once the developer starts working on the bug, he/she changes the
status of the bug to Open to indicate that it is being worked upon to
rectify.
 Fixed:
Once the developer makes necessary changes in the code and verifies
the code, he/she marks the bug as Fixed and passes it over to the
Development Lead in order to pass it to the Testing team.

Pending Retest:
After the bug is fixed, it is passed back to the testing team to get
retested and the status Pending Retest is assigned to it.

Retest:
The Test lead changes the status of the bug, which is previously
marked with Pending Retest to Retest and assigns it to a tester for
retesting.

Closed:
After the bug is assigned a status Retest, it is again tested. If the
problem is solved, the tester closes it and marks it with Closed
status.
 Reopen:
If after retesting the software for the bug opened, if the system
behaves in the same way or same bug arises once again, then the
tester reopens the bug and again sends it back to the developer
marking its status as Reopen.

Pending Rejected:
If the developers think that a particular behavior of the system, which
the tester reports as a bug has to be same and the bug is invalid, in
that case, the bug is rejected and marked as Pending Reject.

Rejected:
If the Test Lead finds that the system is working according to the
specifications & the bug is invalid as per the explanation from the
developer, he/she rejects the bug and marks its status as Rejected.
 Postponed:
Sometimes, testing of a particular bug has to be postponed for
an indefinite period. It may occur because of many reasons,
such as unavailability of Test data, unavailability of particular
functionality etc. That time, the bug is marked with Postponed
status.

Deferred:
In some cases a particular bug stands no importance and is
needed to be/can be avoided, that time it is marked with
Deferred status
 Thinking about Bug Lifecycle
States in the bug report lifecycle or workflows represents key
players in bug find/ repair
Transition between states represent handoffs between those key
players

What does your

current lifecycle tell
you about your key
players and Could you change your
handoffs? bug lifecycle to do
better job of capturing
the real underline
processes, agreements,
handoffs and players
 Bug Life Cycle
There are 6 cycles a bug can pass through:

New Assigned Rejected

New Assigned Open Fixed Pending Retest Verified
Closed
New Assigned Open Fixed Pending Retest Reopen
New Assigned Rejected (NR)
New Assigned Open Postponed
New Assigned Open Deferred
 How do I find out a bug?

Basically, test cases/scripts are run in order to find out any

unexpected behavior of the software product under test. If any
such unexpected occurs, it is called as a bug.
behavior or exception
 What is a Bug Report?

A bug report is a description of a potential/ perceived problem

with the system behavior.
It is a vehicle to communicate the problem to various
stakeholders such as developers, managers, marketing and
other people.
Bug reports can be filed by any of the stakeholders namely
testers, developers, users etc.
Bug reports are acted upon and resolved by stakeholders
 Bugs and Bug Reports
Bug: problem present in system under test that causes it to
fail to meet reasonable expectations
Bug report is a technical document
Describes failure mode in system under test

The most tangible information product of testing

Written to increase product quality

Documents a specific quality problem in system under test

Communicates to the project team

Not a management problem escalation tool

Build not delivered on time is not a bug report summary

Build 781 fails to install is a bug report summary

 Bug Reporting Basics
A bug report is not a bug report till the bug has been proven to
be a bug. It is an incident report till then. However, for
simplicitys sake we call all incident reports as bug reports
A bug should be written with appropriate title, description,
severity, priority, environment, dependencies and other relevant
fields.
A developer reading a bug should be able to reproduce the bug
easily by reading the bug report.
A bug report should be raised in time. Late bug reports stand
to lose their significance or cause potential risks to the project.
 How to report a bug?
Its a good practice to take screen shots of execution of every
step during software testing.

When using Bug-Reporting tool, Bug ID is generated for the

reported bug. All the mandatory fields from the contents of bug
(such as Project, Summary, Description of the bug, Status,
Detected By, Assigned To, Date Detected, Actual Date of
Closure, Severity, Priority etc.) are filled. The screen-shots
taken at the time of execution of test case are attached to the
bug for reference by the developer.

If no bug-reporting tool is used, then the test case is written in

a tabular manner in a file with columns containing Bug ID,
Summary, Description of the bug, Test case ID, Test Step
Description, Detected by, Assigned to. The file containing test
case and the screen shots taken are sent to the developers for
reference.
 Contents of the logged bug
When a tester finds a defect, he/she needs to report a bug and enter
certain fields, which helps in uniquely identifying the bug reported by
the tester.
The contents of a bug are as given below:

Bug ID: This is a unique ID (number generated for the bug at the
time of reporting) which identifies the bug.
Project: Name of the project under which the testing is being carried
out.
Summary: Description of the bug in short, which will help in
identifying the bug.
Description: Detailed description of the bug. It includes the actual
steps performed by the tester for which the application failed. At the
end, the actual results obtained and expected result are mentioned.
 Date Detected: Date on which the bug was detected and reported.

Detected By: Name of the tester who detected/reported the bug.

Assigned To: Name of the developer who is supposed to fix the

bug.

Actual Date of Closure: Actual date when the bug is closed. i.e.
date at which the bug was fixed and retested successfully.

Priority: Medium, Low, High, Urgent

Severity: Medium, Low, High, Urgent

 Status: This field displays the current status of the bug. A
status of New is automatically assigned to a bug when it is
reported by the tester for the first time. The status is changed
to as per the progress of bug fixing process.

Attachment: Sometimes it is necessary to attach screen-shots

for the tested functionality that can help the tester in explaining
the tests he had done and also helps developers in re-creating
the similar testing condition.

Test Case ID: This field contains the ID of the test case as in
the UTC, that failed for the bug.
 The Audience for Bug Report
First customer of a bug report is generally the developer/
development manager.
Dev manager needs to assign bugs to appropriate
developer
Developer needs to look at assigned bugs and fix then in
a priority order
Second customer of the bug report is generally the tester who
raised the bug
To provide more information or clarification
Verify the fix if the bug has been fixed
 Other Audience

Test Manager
Development Manager
Program Manager
Product Manager
Management Team
 Impact of Bad Bug Reports
Developer might flip the Bozo bit for the tester writing
bad bug report
Important problem may not be fixed
Top management may take wrong decision on what to do
with the bug
Problem may not be reproduced
Testers reputation and consequently career growth may
be adversely impacted.
 Are Bad Reports a Problem?
Programmers return many bug report as work-as-designed,
irreproducible, no-fault-found, leading to....
Wasted time in writing the report
Frustration for tester and developer alike
Loss of test team credibility
No increase in product quality
Bug reports can be irreproducible due to.
Intermittence
Inconsistent test/development environment
Disputes over correct behavior

But many irreproducible bug reports are simply bad bug reports,
poorly conceived and poorly written
 Importance of Good Bug Report
A good bug report
Helps developer to resolve the problem faster
Helps tester (including testers other than who raised the
bug) close the fixed bug faster
Helps top management take fix/ do not fix /defer type
of decision faster
A bug report is window into the mind of a tester. You
should aim at providing the best view through that window.
 Ten Steps to a Good Bug Report
Structured: test Carefully
Reproduce: test it again
Isolate: test it differently
Generalize: test it else where
Compare: review similar test result
Summarize: relate test to customer
Condense: trim unnecessary information
Disambiguate: use clear words
Neutralize: express problem impartially
Review: Be sure

Good bug report on a problem can differ in style and content

 Structure
Structured Testing foundation to good bug report
use deliberate, careful approach to testing
Follow written test cases or run automated ones per
written or standardized process
Use charters to structure exploratory testing
Take careful notes
Bug reporting begins when expected and observed result
differ
Sloppy testing result in sloppy bug report
 Reproduce
Always check reproducibility of failure as a part of writing
bug report.
Three times a good rule of thumb
Document a crisp sequence of action that will reproduce
the failure.
Report intermittent, hard-to-repeat failure.
Note failure incident rate ( e.g. 1 in 3 times)
Summary should mention intermittence
Clean set of step to reproduce addresses the
irreproducible issue head-on
 Isolate
Change Variable that may alter symptom
Make changes one by one
Requires thought and understanding of system under
test
May not be immediate obvious
Can be extensive
Match amount of effort to severity of problem
Avoid getting into debugging activity
Good isolation shows due diligence and gives developer
head start on debugging
 Generalize
Look for related failure in system under test
Does the same failure occur in other module or location

Are there more severe symptoms of the same fault

Avoid confusing unrelated problems

Same symptoms can arise from different bugs

Generalizing reduces duplicate bugs reports and refines

understanding of failure
 Compare
Examine result for similar tests
Same test run against earlier version

Similar conditions, other tests, same version

Is failure a regression
Change introduces defects not in earlier version

Usually found when previously pass test fail

Not always possible

Test previously blocked, reinstall impractical

Tested feature unavailable in earlier version

 Summarize
Put a short tag line in each report
Capture failure and impact on customer
Analogy: Bumper sticker
Harder than it seems
Tester must invest time in summary
Advantages of good summaries
Get management attention
Help set priorities
Name bug report of developer

The summary if often the only part of the bug report read
 Condense
Eliminate extraneous word or steps
Reread report carefully

Avoid both cryptic commentary and droning on

Are any details or actions irrelevant ?

Everyones time is precious
so dont waste any of it on unnecessary verbiage

but dont cut any meat, either

 Disambiguate

Remove, rephrase or expand vague misleading or

subjective words and statements
Make sure that report is not subjected to
misinterpretation
Goal: Clear, indisputable statement of facts
Lead developer by the hand to bug
 Neutralize
Deliver bad news gently
Be-fair-minded in wording and implications
Avoid:
Attacking developers

Criticizing the underlying error

Attempting humor

Using sarcasm

Temper tantrums?

Confine bug reports to statements of facts

You will never know who will read the report

 Review
Each tester should submit each bug report to one or more test
peers for a review
Reviewing peers should:
Make suggestions to improve report

Ask clarifications questions

Even challenge bugginess if appropriate

Test team should only submit best possible bug reports, given
time constraints appropriate to priority of bug
 What do Bug tracking Tool Track?
Bug Tracking Tolls: Database that manage narrative and
classificatory information
Failure Descriptions: Narrative describing observed
problem
Status and Resolution: Narrative describing the steps to
closure and end findings
Version tested, state, severity, priority etc: classifying the
bug
The Failure description
The heart of the bug report
 Severity Vs. Priority
Severity: effect of failure Priority: effect of failure on
(immediate or delayed) on user/ customer/ operator
system
1. Complete loss of value
1. Loss of data, hardware 2. Unacceptable loss of value
damage, or a safety issue 3. Possibly acceptable
2. Loss of functionality with reduction in value
no workaround
3. Loss of functionality with a 4. Acceptable reduction in
workaround value
4. Partial loss of functionality 5. Negligible reduction in
5. Cosmetic or trivial value

It is easy to assign severity, but much harder to assign priority.

Priority can be adjusted during bug triage ( more to come )
 Tips
Report your bug in a way that allows reader to understand the
full impact of the problem
Dont edit others Bug Report. Add comments like [CK 12/08/06]
Report design errors
Keep clear difference between severity and priority
Failure is a symptom of an error, not an error itself
Dont just make a minor bug reproducible but exploit it to see
the real impact of the underlying fault
Be conscious of the processing cost of your bug report
If you are not sure about the bug, get opinions from
testers/developers.
Every bug deserves its own report
Test Environment often plays a bug role in reproducibility of a
problem. Make sure you capture all the required information.
 More Tips
Bug reports are not against any developer. Bug reporting is
just a tool to convey product shortcomings
Report the problem clearly, but dont try to solve it
Meet the programmer who will read your report
If developer tell you not to report a bug and that they will
fix it on the sly, please say a polite NO and log the bug
When the programmer says it is fixed, make sure it isnt still
broken
Verify the bug fixes promptly and if they fail, talk to
programmers
Dont let deferred bug disappear Appeal them immediately