Web development process

Simple bug tracking system using Excel spreadsheet

1. The bug life workflow is as follow (click on image to enlarge):
   
   
   
   
2. Create a project folder, for example: C:\myproject
   
   
3. Download the bug_report_template.doc into this folder.
   
   This Word document describes what a bug report should contain. The key to making a good bug report is providing the developers with as much information as necessary. The more information you supply, the easier it will be for the developers to determine the problem and fix it.
   
   To create a bug report:
   
   
   • First create a subfolder with the bug id as its folder name, for example: C:\myproject\15
   • Copy the C:\myproject\bug_report_template.doc into C:\myproject\15
   • Rename the document into bug_report_15.doc
   • Place all additional information regarding this bug such as screen dumps and log files in C:\myproject\15
   • Edit bug_report_15.doc
   
   
   

   Column	Value	Description
   Bug#	-	All bugs must have an unique id number. The ids are sequentially numbered. The last used bug id can be found in the bug_tracking_template.xls spreadsheet.
   Originator	-	The person (also known as a bug reporter) who has found the bug and created the bug report. Developers sometimes needs to contact the originator that is why the originator's email and phone is helpfull.
   Submit date	-	The date (dd-mm-yyyy) when the bug report is submitted.
   Summary	-	A short description (recommened two lines) of the bug. A more detailed description can be found in the description field.
   Severity	blocker critical major minor trivial enhancement	Indicates how damaging the bug is and is set by the bug reporter. Blocks development and/or testing work. Crashes, loss of data, severe memory leak, performance problem. Major loss of function. Minor loss of function, or other problem where easy workaround is present. Cosmetic problem like misspelled words or misaligned text. Request for enhancement.
   Product		If you are developing more than one product, identify the product in question where this bug is found.
   Component		A product can consist of components. Identify the component in question where this bug is found.
   Version		In most cases the product is not static. Developers need to know in which version the bug is found.
   Platform	PC Macintosh	The platform used when this bug is found.
   OS	Windows Mac Linux	The operating system used when this bug is found.
   Browser	IE 6.0 Firefox 1.5	The browser used when this bug is found.
   URL		If you are developing a web based product, identify the URL where this bug is found.
   Description		Explain in detail what is wrong. It is often helpfull to list the steps taken to recreate the bug. Include all proper menu names, don't abbreviate and don't assume anything. After you've finished writing down the steps, follow them and make sure you've included everything you type and do to get to the problem. If there are parameters, list them. If you have to enter any data, supply the exact data entered. Go through the process again and see if there are any steps that can be removed. Remember to report one problem at a time, don't combine bugs in one report. If available, supply any supporting documentation e.g. log files and screen dumps.

   
   
   
   
   
   
4. Download the bug_tracking_template.xls into folder C:\myproject.
   
   This Excel spreadsheet tracks all reported bugs. Each time a bug report is created, this bug must also be reported in the bug_tracking_template.xls spreadsheet.
   
   Only column Bug#, Originator, Submit date, Summary and Severity must be filled by the bug reporter.
   
   

   Column	Value	Description
   Bug#	-	All bugs must have an unique id number. The ids are sequentially numbered. This field is set by the bug reporter.
   Originator	-	The person (also known as a bug reporter) who has found the bug and created the bug report. This field is set by the bug reporter.
   Submit date	-	The date (dd-mm-yyyy) when the bug report is submitted. This field is set by the bug reporter.
   Summary	-	A short description (recommened two lines) of the bug. A more detailed description can be found in the bug report. This field is set by the bug reporter.
   Severity	blocker critical major minor trivial enhancement	Indicates how damaging the bug is and is set by the bug reporter. Blocks development and/or testing work. Crashes, loss of data, severe memory leak, performance problem. Major loss of function. Minor loss of function, or other problem where easy workaround is present. Cosmetic problem like misspelled words or misaligned text. Request for enhancement.
   Priority	P1 P2 P3 P4 P5	This field is set by the Software Review Board where both the project manager and client decides in which order the bugs should be fixed in. The highest priority is P1 and the lowest is P5. Priority is determined by combining severity (above) with the frequency of the problem and sometimes business needs (e.g. fixed advertising campaign date). critical high medium low unkown
   Assigned to	-	The lead developer assigns the bug to a developer who will be responsible for fixing this bug. This field is set by the lead developer.
   Resolution	fixed invalid wontfix cantfix needinfo duplicate worksforme	Indicates what happened to the bug and is set by the developer. A fix for this bug is made. The problem described is not a bug. An explanation can be found in the bug reports description field. The problem described is a bug which will never be fixed. An explanation can be found in the bug reports description field. The problem described is a bug which can not be fixed because of certain circumstances. An explanation can be found in the bug reports description field. The developer needs more information from the bug reporter. The requested information can be found in the bug reports description field. The problem is a duplicate of an existing bug. The duplicated bug# will be reported in the bug reports description field. All attempts at reproducing this bug were futile, and reading the code produces no clues as to why the described behavior would occur. If more information appears later, the bug can be reopened. An explanation can be found in the bug reports description field.
   Status	new assigned resolved verified reopend closed	Indicates the general health of a bug. Bugs that are first opened and has not been assigned to anybody yet. This status is set by the bug reporter. The bug has been assigned to a developer who will take charge of it. This status is set by the lead developer. A fix for the bug has been implemented and it is awaiting verification by QA (Quality Assurance). This status is set by the developer. The QA has verified the validity of the bug fix. This status is set by the QA. The QA is usually a (lead) developer verifying the bug fix and also reviews the code if it complies to coding, security and other standands. The bug was previously resolved, verified or closed but it has been reopened. This status is set by the QA or tester. The tester verified the bug fix. This status is set by the tester. This field is set by the bug reporter, lead developer, developer, QA or tester. See bug life workflow.