Manual Testing : Bug Report

a bug, a defect, and an error:
Mistake (an error): A human action that produces an incorrect result.
- mistake made in translation or interpretation.
- lots of taxonomies exist to describe errors.
Fault: An incorrect step, process or data definition.
- manifestation of the error in implementation
- this is really nebulous, hard to pin down the 'location'
Failure: An incorrect result.
Bug: An informal word describing any of the above. 
I have seen these arbitrary definitions:
Error: programmatically mistake leads to error.
Bug: Deviation from the expected result.
Defect: Problem in algorithm leads to failure.
Failure: Result of any of the above.
Compare those to these arbitrary definitions:
Error: When we get the wrong output i.e. syntax error, logical error
Fault: When everything is correct but we are not able to get a result
b We are not able to insert any input
                  In other words, the software industry can still not agree on the definitions for bug, defect, error, fault, or failure. In essence, if you use the term to mean one specific thing, it may not be understood to be that thing by your audience. However, since the terms are not used correctly, you should learn the meaning of them where you work. They also could go under the name of PR (Problem Report), or CR (Change Request).
         One of the most important (and most common) things an SQA Engineer does is to write "bug reports". How well you report a bug directly affects how likely the programmer is to fix it. You should spend a minimum of time needed to describe a problem in a way that maximizes the probability that it will be fixed. The content and manner of your reports affect that probability.
How to Write a Fully Effective Bug Report?
 To write a fully effective report you must:
- Explain how to reproduce the problem - Analyze the error so you can describe it in a minimum number of steps.
- Write a report that is complete and easy to understand.
              Write bug reports immediately; the longer you wait between finding the problem and reporting it, the more likely it is the description will be incomplete, the problem not reproducible, or simply forgotten.
                 Writing a one-line report summary (Bug's report title) is an art. You must master it. Summaries help everyone quickly review outstanding problems and find individual reports. The summary line is the most frequently and carefully read part of the report. When a summary makes a problem sound less severe than it is, managers are more likely to defer it. Alternatively, if your summaries make problems sound more severe than they are, you will gain a reputation for alarmism. Don't use the same summary for two different reports, even if they are similar. The summary line should describe only the problem, not the replication steps. Don't run the summary into the description (Steps to reproduce) as they will usually be printed independently of each other in reports.
                    The most controversial thing in a bug report is often the bug Impacts: Low, Medium, High, and Urgent. Report should show the priority which you, the bug submitter, believes to be appropriate and does not get changed.

Was the bug reproducible?

Tester name
Test date
Bug reporting date
Name of developer/group/organization the problem is assigned to
Description of problem cause
Description of fix
Code section/file/module/class/method that was fixed
Date of fix
Application version that contains the fix
Tester responsible for retest
Retest date
Retest results
Regression testing requirements
Tester responsible for regression tests
Regression testing results

              A reporting or tracking process should enable notification of appropriate personnel at various stages. For instance, testers need to know when retesting is needed, developers need to know when bugs are found and how to get the needed information, and reporting/summary capabilities are needed for managers.

Bug Impacts
Low impact:
       This is for Minor problems, such as failures at extreme boundary conditions that are unlikely to occur in normal use, or minor errors in layout/formatting. These problems do not impact use of the product in any substantive way.
Medium impact:
             This is a problem that a) Effects a more isolated piece of functionality. b) Occurs only at certain boundary conditions. c) Has a workaround (where "don't do that" might be an acceptable answer to the user). d) Occurs only at one or two customers. or e) Is very intermittent
High impact:
                  This should be used for only serious problems, effecting many sites, with no workaround. Frequent or reproducible crashes/core dumps/GPFs would fall in this category, as would major functionality not working.
Urgent impact :
            This should be reserved for only the most catastrophic of problems. Data corruption, complete inability to use the product at almost any site, etc. For released products, an urgent bug would imply that shipping of the product should stop immediately, until the problem is resolved.
Defects Severity and Priority
        It depends entirely on the size of the company. Severity tells us how bad the defect is. Priority tells us how soon it is desired to fix the problem.
            In some companies, the defect reporter sets the severity and the triage team or product management sets the priority. In a small company, or project (or product), particularly where there aren't many defects to track, you can expect you don't really need both since a high severity defect is also a high priority defect. But in a large company, and particularly where there are many defects, using both is a form of risk management.
            They use a four-point severity rating (rather than three): Catastrophic; Critical; Marginal; Negligible. They then use a five-point (rather than three) probability rating: Frequent; Probable; Occasional; Remote; Improbable. Then rather than using a mathematical calculation to determine a risk level, they use a predefined chart.
Blocker: This bug prevents developers from testing or developing the software.
Critical: The software crashes, hangs, or causes you to lose data.
Major: A major feature is broken.
Normal: It's a bug that should be fixed.
Minor: Minor loss of function, and there's an easy work around.
Trivial: A cosmetic problem, such as a misspelled word or misaligned text.
Enhancement: Request for new feature or enhancement.