Web development process

 
 
A web development process can be divided into different life cycle steps. For each step certain standards and procedures can be applied. Often "in-house" standards are used regarding documents, coding etc. However it would beneficial to your company if your procedure conforms to quality standards.

In this guide the classical software life cycle model (ESA PSS-05) that was standardised by the European Space Agency is adopted as a reference model for the web development life cycle. There are some changes and additions made on the ESA PSS-05 standards.

The document complies with the Software Transfer Document (STD) from the Software Engineering Standard, as set by the European Space Agency [ESA].

This guide describes how to apply the "ESA Software Engineering Standards to small software projects" for web projects. This guide is also nickname "ESA PSS-05 lite".

rss feed

Quick guides






Simple bug tracking system using Excel spreadsheet



Information
For large projects it is recommended to use a more advanced bug tracking tool such as Bugzilla. For very small projects you can use this simple bug tracking system based on an Excel spreadsheet.

Operating system used
Windows XP Home Edition Version 5.1 SP 2

Software prerequisites
Microsoft Excel
Microsoft Word


Procedure
  1. The bug life workflow is as follow (click on image to enlarge):

    Bug life workflow.

  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
    1. blocker
    2. critical
    3. major
    4. minor
    5. trivial
    6. enhancement
    Indicates how damaging the bug is and is set by the bug reporter.

    1. Blocks development and/or testing work.
    2. Crashes, loss of data, severe memory leak, performance problem.
    3. Major loss of function.
    4. Minor loss of function, or other problem where easy workaround is present.
    5. Cosmetic problem like misspelled words or misaligned text.
    6. 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
    1. PC
    2. Macintosh
    The platform used when this bug is found.
    OS
    1. Windows
    2. Mac
    3. Linux
    The operating system used when this bug is found.
    Browser
    1. IE 6.0
    2. 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
    1. blocker
    2. critical
    3. major
    4. minor
    5. trivial
    6. enhancement
    Indicates how damaging the bug is and is set by the bug reporter.

    1. Blocks development and/or testing work.
    2. Crashes, loss of data, severe memory leak, performance problem.
    3. Major loss of function.
    4. Minor loss of function, or other problem where easy workaround is present.
    5. Cosmetic problem like misspelled words or misaligned text.
    6. Request for enhancement.
    Priority
    1. P1
    2. P2
    3. P3
    4. P4
    5. 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).

    1. critical
    2. high
    3. medium
    4. low
    5. 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
    1. fixed
    2. invalid
    3. wontfix
    4. cantfix
    5. needinfo
    6. duplicate
    7. worksforme
    Indicates what happened to the bug and is set by the developer.

    1. A fix for this bug is made.
    2. The problem described is not a bug. An explanation can be found in the bug reports description field.
    3. The problem described is a bug which will never be fixed. An explanation can be found in the bug reports description field.
    4. 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.
    5. The developer needs more information from the bug reporter. The requested information can be found in the bug reports description field.
    6. The problem is a duplicate of an existing bug. The duplicated bug# will be reported in the bug reports description field.
    7. 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
    1. new
    2. assigned
    3. resolved
    4. verified
    5. reopend
    6. closed
    Indicates the general health of a bug.

    1. Bugs that are first opened and has not been assigned to anybody yet. This status is set by the bug reporter.
    2. The bug has been assigned to a developer who will take charge of it. This status is set by the lead developer.
    3. A fix for the bug has been implemented and it is awaiting verification by QA (Quality Assurance). This status is set by the developer.
    4. 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.
    5. The bug was previously resolved, verified or closed but it has been reopened. This status is set by the QA or tester.
    6. 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.