1.

Following Severity Levels are assigned during the Testing Phase:

Critical – is the most dangerous level, which does not permit continuance of the
testing effort beyond a particular point. Critical situation can arise due to popping
up of some error message or crashing of the system leading to forced full closure
or semi closure of the application. Criticality of the situation can be judged by the
fact that any type of workaround is not feasible. A bug can fall into "Critical"
category in case of some menu option being absent or needing special security
permissions to gain access to the desired function being tested.
High – is a level of major defect under which the product fails to behave according
to the desired expectations or it can lead to malfunctioning of some other functions
thereby causing failure to meet the customer requirements. Bugs under this
category can be tackled through some sort of workaround. Examples of bugs of
this type can be mistake in formulas for calculations or incorrect format of fields in
the database causing failure in updating of records. Likewise there can be many
instances.
Medium – defects falling under this category of medium or average severity do
not have performance effect on the application. But these defects are certainly not
acceptable due to non-conformance to the standards or companies vide
conventions. Medium level bugs are comparatively easier to tackle since simple
workarounds are possible to achieve desired objectives for performance. Examples
of bugs of this type can be mismatch between some visible link compared with its
corresponding text link.
Low - defects falling under low priority or minor defect category are the ones,
which do not have effect on the functionality of the product. Low severity failures
generally do not happen during normal usage of the application and have very less
effect on the business. Such types of bugs are generally related to looks & feel of
the user interface & are mainly cosmetic in nature.

2. Mastering the Art of Effective Bug Reporting:

All software testers strive to achieve the prime aim of hunting maximum number of bugs in
the software. When some build gets ready for testing, the main aim of the tester is to dig
out maximum possible bugs from each & every corner. To achieve perfection in this task
testing is performed from different angles. The application under test is subjected to the
rigors of the following type:

# Boundary value analysis

# Validation Testing
# Verification Testing
# GUI Testing
# Interoperability Testing
# Integration Testing
# Functional Testing – from Business concept Point of view
# Backend Testing
# Security Testing etc.

With such activities tester needs to go into ample depth of the software application taking
care of the prime requirements of the business.
It is a known fact that mere awareness about the Bug is insignificant unless it is backed by
a proper set of documentation. This gives rise to the need of "Bug Reports". These bug
reports form the primary work output of a tester. Bug reports is an important object
frequently viewed even by the persons other than the testing team. Such Bug Reports play
an extremely crucial role in various phases of the SDLC. These Bug Reports are frequently
used by the testing engineers, code developers, project managers and finally by the clients
as well. The clients are becoming quite demanding these days & demand the test / bug
reports. Hence the Bug Reports are of great significance & are referred several times by all
concerned.
After the testers test the software & report the bugs to the team of developers, who need to
work on the same, some sort of unpleasantness is bound to arise. This is because, no-one
relishes his mistakes being told. Testers usually come across some sort of humiliation & cold
wars like situations develop. The peculiar situation arises when both testers as well the
developer mean to say a particular thing in the same way & both may be right from their
point of view, however confrontation may arise due to difference of projection of their view
point. Thus we can say that key attribute of a best tester is his ability to find large number
of bugs as well as his ability to get the maximum number of bugs fixed in his application.

Reporting of Bugs in an effective way is an Art:

Bug Report provides an effective feel of the failure to the developers. A good Bug Report is
the one, which is prepared with so much clarity that developers would feel a sense of
pleasure in fixing the bugs. However poorly written bug reports are likely to backfire from
the development team with comments like – it is not a bug and It cannot be reproduced.
Likewise there can be numerous comments of similar nature.
Thus an intelligent tester understands the great importance of his "Bug Report" & prepares
an unquestionable Bug Report to the best of his ability & utmost clarity to avoid any type of
controversy at any stage.

Important Elements of a Bug Report:

For an effective communication with the code developers, following information pertaining
to the Bug needs to be captured & be clearly conveyed in the Bug Report. Such information
is of great help to the developers in understanding the Bug, get an idea of the severity of
the Bug & he should be able to reproduce the Bug if need be.

As a matter of two way communication, the developer is equally expected to describe the
cause of the problem / Bug, steps taken to fix the Bug / Fix description, steps taken to
verify the fix and all information helpful in preventing occurrences of such Bugs in the
future.
Bug ID : A unique number for the identification of the bug.
Bug State: During the Life Cycle of the Bug, it passes across various states before getting
closed (as described in the Article "Know All about States of Bug during Life Cycle"). The
present state of the Bug like New Bug, Assigned Bug, Fixed Bug, Closed Bug etc. is an
essential part of the Bug Report.
1) Details of Application: Like application name, version, URL, details of database if any
etc.
2) Component or Sub-component: referring to the part of the application where the bug
was detected by the tester
3) Details of the Environment: Like Name of the Operating System details of the
Hardware platform etc.
4) Bug Severity / Criticality Level: Like Critical / Major / Average or Minor
5) Bug Priority: When many bugs with similar severity are present in the system, priorities
can be assigned to such bugs according to which these bugs shall be fixed.
6) Test Case ID: A unique number / Name for the identification of the Test case.
7) Title / Subject of the Bug: A brief / may be one line description of the bug
8) Bug Description: A detailed description of the bug.
9) Steps to Reproduce: A step by step explanation of method to reproduce the bug.
10) Details of Input Data: A detailed description of the input data, based upon which bug
had been detected.
11) Additional information: Like Screen Shots, Error Messages, Log files if any etc. are
extremely helpful in finding the cause of the problem & arriving at a solution to fix it.
12) Details of the Tester: Details Like a) Name b) Contact information etc.
13) Bug Event Details: Details like the Date & Time at which Bug had been reported
14) Bug Assignment Details: Details like the name of the developer to which the bug has
been assigned.
15) Cause of the Problem: A detailed description of the causes leading to the problem
16) Solution / Fix: A detailed explanation of the steps undertaken to fix the problem.
17) Problem Area: Identification of the Code section / file / module / class where the fix
was done, including the details of method used to fix the problem.
18) Version Details: Details like the Date of Fix, Version of the file which contains the
concerned fix

3 Nine Tips for an Effective Bug Reporting

It is important that a software tester reports everything what he feels. A software
tester role is that of a catalyst in any team. He makes up the team on one hand and
breaks up the application on the other. It is important to clearly understand all the
issues in the application may be big or small with due course of understanding in terms
of business and the application. Therefore a strong Bug Report serves as a definite
proof in Software Development Life Cycle, provided the status of bugs is updated at all
stages. Sole objective of your reporting a bug is that your intention is to get the bug
fixed.
1. Clarity of Bug Description – Bug description refers to a small statement, which
briefly points towards the exact problem. May be the problem requires a couple of steps
to reproduce it, however this small statement of bug description must be able to
communicate the exactly nature of problem. For instance in case of a problem
concerning an error from the server, the bug description could clearly elaborate the
meaning by stating that the server error takes place while performing such an such
operation.

2. Don’t Pass your Verdict – even if you are brimming with confidence about
authenticity of the bug detected by you, avoid writing a bug report which would reflect
as if you are trying to pass your verdict on the genuinity of the bug. In every
probability this could initiate a controversy which would reflect your superiority complex
as a tester. Your main aim should be to keep your bug report conclusive supporting
your bug plus the sole motive must be to get the bug closed ultimately. Try to use
diplomacy in bug report, instead of using authoritative statements in favor of your bug
thereby making your bug report unpleasant, best way is to be suggestive. Such an
approach shall always be taken in good spirit.

3. Steps to Reproduce – How to reach the precise point of bug, with due explanation
of the set of conditions so as to reproduce it must be clearly defined in the bug report.
For instance, for graphical software, tester needs to communicate to the developers, as
to what he had done before getting the bug. The details must be elaborated like which
buttons were pressed and in what order. For a program executed by keying in a
command across the prompt, the details of the command typed before getting the bug
needs to be indicated precisely.

4. Use of Simple Language – People do not like to read long paragraphs containing
complex jargons & tongue twisters. A good bug report contains small bulleted like
containing small but clear sentences. It should describe the observations relevant to the
concerned bug only. Do not make the bug report unnecessarily complex and lengthy by
writing too many facts. Avoid narrating superfluous details, which may not be of any
help in reproducing the bug. Do not write things, which are commonly known, to
everyone.

5. Quote-Relevant Examples – In majority of situations, we find that for reproducing

a particular bug, some particular group of inputs is essential. Thus instead of making
vague statements like feed invalid name of a person in the contact list, & save; it can
be said that feed an invalid input like 035bbb@$% in the name field & click save. In
order to get the bug fixed quickly tester must try to help the programmers by providing
all the relevant information / to-the-point information.

6. Provide Back References – In case a particular bug happens to contradict the

specification document or any other document related to the project; the bug report
must provide adequate reference to the particular chapter or clause number of the
concerned document being contradicted.

7. Allocate Bug Priority & Severity – Bug reporting is not complete without
earmarking the level of Bug Severity & Bug Priority.

Bug Severity: refers to the quantum of danger as to how badly the bug can harm
the system. It describes as to how bad the bug is. Severity is a feature of constant
nature associated with the bug.
There are three levels of Bug Severity, which are described as under:
Severity level - Critical: is the most dangerous level, which does not permit
continuance of the testing effort beyond a particular point. Critical situation can arise
due to popping up of some error message or crashing of the system leading to forced
full closure or semi closure of the application. Criticality of the situation can be judged
by the fact that any type of workaround is not feasible. A bug can fall into "Critical"
category in case of some menu option being absent or needing special security
permissions to gain access to the desired function being tested.
Severity level – High: is a level of major defect under which the product fails to
behave according to the desired expectations or it can lead to malfunctioning of
some other functions thereby causing failure to meet the customer requirements.
Bugs under this category can be tackled through some sort of workaround.
Examples of bugs of this type can be mistake in formulas for calculations or
incorrect format of fields in the database causing failure in updating of records.
Likewise there can be many instances.
Severity level – Medium: defects falling under this category of medium or
average severity do not have performance effect on the application. But these
defects are certainly not acceptable due to non-conformance to the standards or
companies vide conventions. Medium level bugs are comparatively easier to tackle
since simple workarounds are possible to achieve desired objectives for
performance. Examples of bugs of this type can be mismatch between some visible
link compared with its corresponding text link.
Severity level – Low: defects falling under low priority or minor defect category
are the ones, which do not have effect on the functionality of the product. Low
severity failures generally do not happen during normal usage of the application and
have very less effect on the business. Such types of bugs are generally related to
looks & feel of the user interface & are mainly cosmetic in nature.
Bug Priority: refers to the need as to how urgently bug is required to be fixed. It
describes the importance of the bug. Bug priority may change according to the
schedule of testing. There are three levels of Bug Priority, which are described as
under:
High Priority: Such bugs if not fixed immediately, are going to affect the normal
functioning at customer end. Hence such bugs are given immediate or topmost priority
for fixing.
Medium Priority: is allocated to the bugs with major defects having great effect on
the functioning of the customer. Such bugs are allocated great priority so those
related problems are resolved prior to release of the present software version. If
due to some time constraint it is not possible to resolve this issue, some sort of
patch or service pack must be released
Low Priority: is generally allocated to bugs, which do not have significant effect on
the performance of the software at the customer end. Effort is made to resolve such
bugs prior to release of the present version, if this is not feasible due to constraint
of time such fixation can wait till the release of next version.

8. Explain by Screenshots – As per an old saying "A picture is worth more than
100 words". When we encounter an error, it is best to capture the screenshot of the
particular moment. If an error message is seen, its screenshot will help the
developer in having a precise understanding of the problem. This is the stage the
developer does not try to fix the problem, rather focuses his attention to firstly
understand the problem clearly. Such screenshot should be an appendix of the bug
report as evidence. This way tester is able to communicate & explain his bug in a
better way & with more clarity to the developer.
 9. Standby your Genuine Bugs:
Most interesting portion of bug reporting is when the software tester needs to be
standby the bugs found by him & needs to defend that bugs covered under his
report are genuine bugs needing fixation since it is going to affect the performance
of the application. During this the course, the software-testing engineer must be
ready to face situations with the programmers like the few ones mentioned below.
Case 1: Developers usually hit back saying that particular bug can’t be reproduced. The
best way of reporting the bug is practically showing it to the developer. This can be
done by asking them to have a look at the scenario on your computer system, load the
application & provide live demonstration of the problematic event. This would provide
them actual look & feel of the situation as to how you had fired the application, how
you had been interacting with the application & how the software reacts to the inputs
provided. As a best practice avoid reporting of non-reproducible bugs in an enthusiasm
to report maximum number of bugs in shortest possible time.

Case 2: Sometimes the software tester comes across funny circumstances with some
application having inconsistent pattern of failure. Such situations can arise when the
tester encounters pressure of deadlines & the application under test fails, but he faces
embarrassing moments while demonstrating the same to the developers, since the
application behaves normally at that moment. Thus a good tester needs to be patient &
always build a defense mechanism in the form of preserving test data & screenshots
etc. to justify his statements.

Case 3: If the tester provides the developers a big list of various actions & inputs etc.
but the program fails to show anything wrong when executed on the system of the
developer. This means that the tester has not provided sufficient information. It is quite
possible the systems of the developer & the tester differ in some configuration, thereby
causing the fault not to appear on computer system of the developer. It is quite
possible that the tester had misunderstood the expectations of the program, while the
tester & the developer are witnessing the same display, but with a difference in
viewpoint. It might be possible that what appears, as an error to the tester might be
correct from the point of view of the developer. Thus to come out of such situations, it
is preferred to say as to what you had expected & what you had seen exactly & what
had happened.

4. Tips for Describing a Bug Effectively

A Software Bug can be described through detailed explanation of the unexpected behavior
happening as a result of some action performed on the software application.
1) Be specific writing the description of the Bug. Describe the behavior, which was
expected, but did not happen. Describe as to what happened instead. For example the
window closed as against appearing of the pop-up.
2) Description should be in the present tense.
3) Description should not have unnecessary words.
4) Description should not have exclamation points.
5) Always finish the sentences with a period.
6) DON’T USE ALL CAPS - as written here.
7) Format the words in upper and lower case (mixed case).
8) Most essential of all is to describe series of steps required to reproduce the bug.

5. Broad points of variance among Priority & Severity are described

below.
Sr. Priority Severity

1 It is associated with It is associated with

schedule to resolve e.g. out
of many issues to be
tackled, which one should be
addressed first by the order
of its importance or urgency.
benchmark quality or
adherence to standard. It
reflects harshness of a quality
expectation.

2 Is largely related to Business Is related to technical aspect

or Marketing aspect. It is a of the product. It reflects on
pointer towards the how bad the bug is for the
importance of the bug. system.

3 Priority refers to how soon Severity refers to the

the bug should be fixed.
seriousness of the bug on the
functionality of the product.
Higher effect on the
functionality will lead to
assignment of higher severity
to the bug.

4 Priority to fix a bug is The Quality Assurance

decided in consultation with Engineer decides the severity
the client. level. It is decided as per the
risk assessment of the
customer.

5 Product fixes are based on Product fixes are based on

'Project Priorities. Bug Severity.

1) Generally speaking, a "High Severity" bug would also carry a "High Priority" tag along
with it. However this is not a hard & fast rule. There can be many exceptions to this rule
depending on the nature of the application and its schedule of release.

2) High Priority & Low Severity: A spelling mistake in the name of the company on the
home page of the company’s web site is certainly a High Priority issue. But it can be
awarded a Low Severity just because it is not going to affect the functionality of the Web
site / application.
3) High Severity & Low Priority: System crashes encountered during a roundabout
scenario, whose likelihood of detection by the client is minimal, will have HIGH severity. In
spite of its major affect on the functionality of the product, it may be awarded a Low Priority
by the project manager since many other important bugs are likely to gain more priority
over it simply because they are more visible to the client.

6. Various States of a Bug during its Life Cycle:

Bug refers to a fault or defect in software program due to which the software behaves
abnormally. Truly speaking Bugs are inherent to software, rather it is difficult to find a
software without any Bug. Removal of bugs from the software depends upon the efficiency
of the testing activity performed on the software. Bug attracts special concerns which reflect
on the quality of the Application under Test

Life Cycle of Bug:

In software development process, every bug has its own life cycle across which it passes
through before getting closed. As a matter of standardization, specific life cycle is defined
for the Bugs. During its life cycle, the bug attains various states, which are illustrated below

Various States of a Bug during its Life Cycle are:

1. New Bug: When a bug is posted for the first time, its state is called "NEW". This implies
that the bug is not approved yet.
2. Open Bug: Once the software tester posts a bug, the team leader approves it after
satisfying himself about its genuinity, and changes its state to "OPEN".
3. Assigned Bug: Once the lead changes the state to "OPEN", the bug is assigned to the
concerned developer team. The state of the bug is changed now to "ASSIGNED".
4. Test Bug: Once the developer fixes the bug, he transfers the bug to the testing team for
next round of testing. After fixing the bug & prior to releasing it back to the testing team,
the state of the bug is changed to "TEST". In other words, the state "Test Bug" implies that
the bug has been fixed and is released to the testing team.
5. Deferred Bug: When the bug is expected to be fixed in next releases, its state is
changed to deferred state. Many factors are responsible for changing the bug to this state.
Few of such factors are priority of the bug may be low, lack of time for the release or the
bug may not have major effect on the software.
6. Rejected Bug: If the developer feels that the bug is not a genuine one, he rejects it.
This leads change of state of the bug to "REJECTED".
7. Duplicate Bug: If a particular bug gets repeated more than once or two bugs point
towards the same concept, then the status of one of the bug is changed to "DUPLICATE".
8. Verified Bug: Once the developer fixes the bug and its status is changed to "TEST", the
software tester confirms the absence of the bug. If the bug is not detected in the software,
the tester approves that the bug is duly fixed and changes its status to "VERIFIED".
9. Reopened Bug: If the bug is detected again even after the bug is claimed to be fixed by
the developer, the tester changes its status to "REOPENED". The cycle repeats again &
again till the bug gets ultimately fixed & get closed.
10. Closed Bug: Once the bug is fixed & the tester confirms its absence, he changes its
status to "CLOSED". This is the final state which implies that the bug is fixed, tested and
approved.

As is well known that prevention is better than cure, similarly prevention of defect in
software is much more effective and efficient in reducing the number of defects. Some
organizations focus on discovery of defect and subsequent removal. Since discovering and
removing defects is an expensive and inefficient process, hence It is better & economical for
an organization to focus their major attention on activities which prevent defects.

Typical Lifecycles of Some of the Popular Bugs are:

• Valid Bug:
New -> Assigned -> Fixed but not patched -> Ready for Re-testing ->
Closed & Fix has been Verified
• Invalid Bug:
New -> Not a Bug -> Closed since it is Not a Bug
• Duplicate Bug:
New -> Duplicate Bug -> Closed since it is a Duplicate Bug
• Reopened Bug:
New -> Assigned -> Fixed but not patched -> Ready for Re-testing ->
Reopened -> Fixed but not patched -> Ready for Re-testing -> Closed & has
been Fix Verified
Analysis of Bugs:
Bugs detected & logged during the testing phase provide valuable opportunity to
improve the product as well as the testing processes. The aim of every testing
team remains to achieve zero Customer Bugs. Majority of the Customer Bugs
starts pouring in first 6 Months to 1 year of the product usage.

Immediately after the completion of the product testing, the testing teams should
carry out detailed analysis of the entire set of Invalid Bugs / Duplicate Bugs /
Could_Not_Be_Reproduced Bugs and come up with adequate measures to reduce
their count in future testing efforts.

However once Customer Bugs start pouring in, the testing Team immediately
starts analyzing each one of them & try to find out as to how & why these bugs
have missed during their testing effort and take appropriate measures
immediately.

8. What is that who is responsible for Bugs or Defects in

Software Application?
A few of the following activities or events are responsible for bugs in the software
application.
1) Inadequate understanding / recording of the product needs stated & implied by the
customer.
2) Incorrect or inadequate translation of user needs / requirements to the design team
3) Different interpretation or understanding of the user needs by the developing team.
4) Improper translation of the design to the actual code.
5) Failure of the Testing Process to detect the bugs due to inadequacy of the coverage.
6) Inadequacy of Regression Testing. An attempt to fix a particular bug leads to the birth of
another bug & the process continues.

Action Plan to reduce the Bugs or Defects in software Product

1) Capture, Record & Transmit the Customer needs more precisely.
2) Direct the efforts towards making the development process consistent & with minimal
variations.
3) Strive to detect the Bugs at every stage of the product development during its life cycle.