Professional Documents
Culture Documents
Bug Reporting - Art and Advocacy: What We Did
Bug Reporting - Art and Advocacy: What We Did
Introduction:
As testers, we all agree to the fact that the basic aim of the Tester is to decipher bugs.
Whenever a build appears for testing, the primary objective is to find out as many bugs as
possible from every corner of the application. To accomplish this task as perfection, we
perform testing from various perspectives. We strain the application before us through
various kinds of strainers like boundary value analysis, validation checks, verification
checks, GUI, interoperability, integration tests, functional – business concepts checking,
backend testing (like using SQL commands into db or injections), security tests, and many
more. This makes us to drill deep into the application as well as the business.
We would agree to the fact that Bug Awareness is of no use until it is well documented.
Here comes the role of BUG REPORTS. The bug reports are our primary work product. This
is what people outside the testing group notices. These reports play an important role in the
Software Development Life Cycle – in various phases as they are referenced by testers,
developers, managers, top shots and not to forget the clients who these days demand for
the test reports. So, the Bug Reports are remembered the most.
Once the bugs are reported by the testers and submitted to the developers to work upon,
we often see some kinds of confrontations – there are humiliations which testers face
sometimes, there are cold wars – nonetheless the discussions take the shape of mini
quarrels – but at times testers and developers still say the same thing or they are correct
but the depiction of their understanding are different and that makes all the differences. In
such a situation, we come to a stand-apart that the best tester is not the one who finds
most of the bugs or the one who embarrasses most programmers but is the one who gets
most of the bugs fixed.
Hence it is important that the BUG REPORT be prepared by the testers with utmost
proficiency and specificity. It should basically describe the famous 3 What's, well described
as:
What we did:
• GUI Flaws
• Missing or No Validations
• Error messages
• Incorrect Navigations
Pointers to effective reporting can be well derived from above three What's. These are:
3. STEPS should be clear with short and meaningful sentences – nobody would wish
to study the entire paragraph of long complex words and sentences. Make your report step
wise by numbering 1,2,3…Make each sentence small and clear. Only write those findings or
observations which are necessary for this respective bug. Writing facts that are already
known or something which does not help in reproducing a bug makes the report
unnecessarily complex and lengthy.
4. Cite examples wherever necessary – combination of values, test data: Most of the
times it happens that the bug can be reproduced only with a specific set of data or values.
Hence, instead of writing ambiguous statement like enter an invalid phone number and hit
save…one should mention the data/value entered….like enter the phone number as
012aaa@$%.- and save.
5. Give references to specifications – If any bug arises that is a contradictive to the SRS
or any functional document of the project for that matter then it is always proactive to
mention the section, page number for reference. For example: Refer page 14 of SRS section
2-14.
6. Report without passing any kind of judgment in the bug descriptions – the bug
report should not be judgmental in any case as this leads to controversy and gives an
impression of bossy. Remember, a tester should always be polite so as to keep his bug up
and meaningful. Being judgmental makes developers think as though testers know more
than them and as a result gives birth to a psychological adversity. To avoid this, we can use
the word suggestion – and discuss with the developers or team lead about this. We can also
refer to some application or some module or some page in the same application to
strengthen our point.
7. Assign severity and priority – SEVERITY is the state or quality of being severe.
Severity tells us HOW BAD the BUG is. It defines the importance of BUG from
FUNCTIONALITY point of view and implies adherence to rigorous standards or high
principles. Severity levels can be defined as follows:
Urgent/Show – stopper: Like system crash or error message forcing to close the window,
System stops working totally or partially. A major area of the users system is affected by
the incident and It is significant to business processes.
Medium/Workaround: When a problem is required in the specs but tester can go on with
testing. It affects a more isolated piece of functionality. It occurs only at one or two
customers or is intermittent.
Low: Failures that are unlikely to occur in normal use. Problems do not impact use of the
product in any substantive way. Have no or very low impact to business processes
State exact error messages.
PRIORITY means something Deserves Prior Attention. It represents the importance of a bug
from Customer point of view. Voices precedence established by urgency and it is associated
with scheduling a bug Priority Levels can be defined as follows:
High: This has a major impact on the customer. This must be fixed immediately.
Medium: This has a major impact on the customer. The problem should be fixed before
release of the current version in development or a patch must be issued if possible.
Low: This has a minor impact on the customer. The flaw should be fixed if there is time, but
it can be deferred until the next release.
8. Provide Screenshots – This is the best approach. For any error say object references,
server error, GUI issues, message prompts and any other errors that we can see – should
always be saved as a screenshot and be attached to the bug for the proof. It helps the
developers understand the issue more specifically.