Software defect report

Purpose of software defect report

To ensure reliable and fast elimination of failures detected by the various test levels, a well-functioning procedure for communicating and managing those incident reports is needed. 

Software Defect Report Process:

1. Analyze
   It involves analysis of the software defect. Analyzing software defect reports ensures proper prioritization. First of all you need to find the root cause. Then Determine if it is reproducible or repeatable. Attempt to isolate the defect. Additional information on how it can be isolated is valuable. Investigate alternative paths to the issue. And finally decide if its worth reporting. Report those defects which are important in the context.
   
   
2. Report
   It involves reporting the software defect. First of all you need to ensure it is not a duplicate. For that talk with the developer. Enter it into the system and make sure it gets fixed. Characteristics of an effective defect report:
   - Numbered (or ID'd)
   - Simple
   - Written
   - Complete
   - Understandable.
   - Explains the problem
   - Includes minimum number of steps to reproduce.
   
   Report Content:
   
   - Identifying information
      ~ Unique number or ID
      ~ Submitter
      ~ Submit date
      ~ Program or Product this is against.
      ~ Version or Revision of the product.
   
   - Description of the problem
        ~ The problem itself.
        ~ The test case used.
        ~ Any other useful information.
        ~ Avoid using vague/confusing terms.
        ~ Avoid uncommon abbreviations.
        ~ Use any standard terminology.
        ~ Pay attention to spelling and grammar.
   
   - Various status indicators.
       ~ Overall report status.
       ~ Severity and priority.
       ~ Current resolution status.
   
   - Comments.
      ~ Analysis notes.
      ~ Resolution notes.
      ~ Tester notes.
      ~ Modification notes.
      ~ Verification notes.
     
   - Miscellaneous information.
      Includes setup information:
      ~ Environment
      ~ Target release
      ~ Closed release
      ~ Closed Date
      ~ Owner
      ~ Tester
      ~ Software Component
      ~ Fix hours/ Test hours
   
   - Supporting Information
      ~ Error printouts
      ~ Screen shots
      ~ The test case itself
      ~ A flash drive with data or flies
      ~ Trace files, error logs, etc
   
   
3. Track
   It should be handles primarily by the defect review board. Ensure progress is made on defects.
   
   
4. Retest
   Retest can have 3 outcomes:
   ~ Problem has indeed been fixed.
   ~ Problem remains (unchanged).
   ~ Problem is replaced by a new problem.
   
   
5. Close
   It involves testing and verification notes.