Good Bug Reporting

Good Bug Reporting

A typical software development process consists of
- Business Analysis team
- Engineering team
- QA team
- Management

Business analysis team
- Concerned with generation of business requirements.
- Are more aware of business aspects than technical aspects.

Engineering team
- Technically oriented
- They consider that the project is their “BABY”.
- Often runs into the QA team on minor misunderstandings.

QA team
- Test to break
- Communicates bugs to the Engineering team.
- Most often runs into confrontation with the Engineering team.
- Are the most misunderstood of the lot for their BREAKING work

Improving Software work products
- Basic objective of the software development process is to develop a quality product for the customer

How is it achieved?
- By developing and testing repeatedly until the desired objectives are met.

Dependencies
- Having a good cycle time between development and testing
- Proper synchronizing between the teams.
- Minimum discrepancies in report which translates down to efficient work cycle.

Bug Report
- The mainstay of the QA team.
- Communicates entire scenarios to the Engineering team for faster resolution and subsequent closure of the bug, hence the bug report must be GOOD and EASY TO UNDERSTAND.

Why Good Bug Report is needed?
- Effective communication on perceived problems/ issues to the Engineering team.
- A good bug report commands respect.
- An effective bug report ensures that nearly all the bugs are fixed/ resolved.

Why do we write bug reports?
- During the testing process, we encounter number of deviations.
- These deviations are put down and communicated to the developer.
- The developer tries to recreate the issue.
- If found, it is resolved/ fixed.

Ineffective report.
- On attempt to recreate, the issue does not crop up.
- The developer finds it difficult to understand and recreate.
- The bug details are ambiguous.

Effect
- The bugs are not fixed.
- What is the tester’s job?
- Report the bug in its true form.
- Put in elaborate details for understandability.
- Ensure that the bug is reproducible.

Good Bug Report – Features
# Your bug detail should have a unique bug ID.
- Easy for traceability
- Easy to automate , if required
- Uniquely identifies an issue to facilitate retrieval and action.

# Your bug should be reproducible
- A reproducible bug ensures resolution
- Every detail to be included in the steps to recreate
- Enables the developer to trace the steps and fix the bug accordingly.

# Be specific in reporting
- A bug detail should include details about a specific issue only.
- The detail should not combine and try to explain different scenarios
- Summary to be included within 100 characters and should clearly indicate what the bug is about.

Bug Report – Format
A typical bug report should contain
- Bug ID
- Reporter
- Product
- Version
- Component
- Platform
- Operating system
- Priority
- Severity
- Status
- Assign to
- URL
- Summary
- Description
- Steps to recreate
- Expected result
- Actual result
- Snapshots (if any)
- Attachments


Additional Tips
# Report the problem immediately
- Will ensure that you do not forget the steps

# Attempt to reproduce the bug atleast thrice before reporting
- Will ensure that the bug is clear, concise and easily understood by the developer.

# Test the bug across similar modules within the application.
- Chances are high to have the bug in other modules too.

# Good bug summary
- A typical summary is written in 100 characters, should comprise of only one sentence.
- Enables the reader to immediately get the gist of the bug.
- Facilitates manual search when the user wants to search for the bug.

# Do a self review before confirming the bug
- A self review will ensure that discrepancies are removed and you have the bug details put in clearly.
- Remove ambiguous sentence from the report.
- Keep off misleading words.

# Avoid rough, abusive language.
- Do not use the bug report to underestimate, criticize or attack the developer.
- It should command respect from the other teams.

# Do not submit proprietary code in the bug report.
- For proprietary code, create a sample to illustrate.

Bug Report – An Example

Bug ID : 101
Reporter : Abhilash Gopi
Product : School Management (SMgmt)
Version : 1.2.7
Component : TimeTable Creation (TIMETABLE_CREATION.ASP)
Platform : Desktop machine (PII)
Operating system: Windows 2K, Windows XP
Priority : High
Severity : High
Status : New
Assign to : Abu
URL : http://SMgmt/TimeTable_creation.asp
Summary : Creation process for timetable takes an unusually long time (as high as 2 hours).
Description :
Tested Date : Feb.14, 2008.
Pre-requisite : Ensure that there are data available for atleast one class before timetable generation can be scheduled.
When the user selects the option "Schedule >> Time Table Generation", it is found to take an unusally long time to generate the time table.

Steps to recreate :
1) Invoke the School management application in the browser.
2) Login with appropriate username/ password (admin/admin)
3) Go to Schedule >> Time Table Generation"
4) Note that the generation process takes around 2 hours and more to generate the timetable.

Expected result:
The timetable generation process takes a long time to complete.

Actual result:
Time table generation being an important part of the application should be completed in a fairly less time.

Snapshots (if any):
Please find attached the image snapshot for your reference.
Attachments