Bug reporting lecture

A defect is nonconformance to requirements or functional specification.
A software error is something that does not correspond to valid Customer’s expectations that are assumed but may be not described in product requirements.
A bug can be result of incorrect environment, configuration or data

It is a technical document written to describe the symptoms of a bug to
communicate the impact of a quality problem,
prioritize the bug for repair,
help the programmer locate the underlying defect and fix it.
Bug Report
The main goal of the bug report is to have a bug fixed

Bug should provide enough information for

Most important bug report’s properties:
Summary
Description
Severity
Steps to Reproduce
Attachment

Bug Tracking systems

Status
Summary
Description
Severity
Steps

Bug Lifecycle

Bug Report: Summary
The ideal summary gives the reader enough information to understand what the problem is.
This is a short description of the problem. Summary is important part of the bug’s report. It should include a brief description that is specific enough in order the reader could visualize the failure. It can include a brief indication of limits or dependencies of the bug.
Example
Bad subject: It’s impossible to save Concept.
Good subject: It’s impossible to save Concept with long description created via HTML Editor

Bug Report: Description
Give detailed and clear description of a problem.
Try to explain why you consider a program behavior as a bug. Give clear information about what you expected to see (expected result).
If there are any special circumstances, define them and provide them here.

‘Steps to reproduce’ is VERY IMPORTANT information in a bug report. It allows developer to reproduce a problem quickly.
Recommendations:
Bug Report: Steps to reproduce
Start from a known place and then describe each step until you hit the bug
Find exact way to reproduce a bug. Try to find the shortest way.
Go through the defined steps a few times.
Describe each action you do in a separate step.
This field is most valuable for developer, because using steps to reproduce is the quicker way to reproduce the problem.

It is very helpful to augment a bug report with a screenshot or some other type of data. It can help in understanding of the problem. If you need to attach a screenshot, don't make it any larger than necessary.
Attachment can be like:
Pictures (screenshots)
Files (any kind of logs)
Documents
Bug Report: Attachments

Bug Report attributes: Severity
Severity tells us how bad the defect is. It defines the seriousness of the bug or its consequence. It’s assigned by tester.
Critical. This should be reserved for the most catastrophic problems only, e.g. a component, module or area crashes or not accessible. A bug causes the restart of the Web Server or Application Server to continue the work. A user needs to reload entered data. Data loss affects the DB in a serious way.
Major. This should be used for only serious problems, effecting many sites. Data loss, crash of the major functionality, crash of a browser client forcing a user to re-login, a problem with highly involved workaround.
Medium. This is a problem that effects a more isolated piece of functionality, problems with a simple workaround.
Minor. These problems do not impact use of the product in any substantive way, it’s a cosmetic problem, such as a misspelled word or misaligned text, minor errors in layout/formatting.

Hints and Tips

A report that says nothing: “It doesn't work!”, “My computer crashed”. We are sorry for your loss, can you give us more information?
A report that gives wrong or incorrect information
A report including grammar or spelling mistakes, or written using not appropriate language. “It’s kinda “sucky”.” This one violates all sorts of rules. What’s kind of “sucky”. For that matter, define “sucky”. Better yet, don’t use the work “sucky” it’s not in the dictionary and most certainly not in good taste.
What is a poorly defect?

Example of bad bug-report

Example of good bug-report

To create effective defect report you should:
Explain how to reproduce the problem. Providing much information as possible about how to reproduce the problem is most effective way to meet the main goal of the bug report – to have the bug fixed.
Describe everything in detail. State what you saw, and also state what you expected to see. Include all the steps and do not miss anything. Give reference to a requirement or part of a functional specification describing how the system should work in this particular case. Provide results you have expected to see.
Make the report easy to understand. Write clearly. Say what you mean, and make sure it can't be misinterpreted. Use simple language: a report has to be easy to understand, there must be exact and clear description of the problem.

Provide additional or any specific information that could help to understand a problem quickly.
Define exact environment under which the problem was found.
Keep the report simple: one bug per one report. If you see two failures, write two bug reports.
Do the basic root cause analysis to pinpoint what exactly caused the failure, and describe it in the bug report. This kind of analysis would reduce the costs of fixing the bug.
Read carefully what you have written in the bug report and make sure that you understand everything perfectly. If you have added steps to reproduce, follow them to make sure you have not missed any step

Remember, that to verify the problem can only the person who found it. Only in this case she can be sure that the bug she saw – fixed.