Proposal for BTS

To:

Project Manager: <Name with held>
Team Leader: <Name with held>

Subject: Project Proposal for I-Bug Tracker.

As we have planned for a bug tracking system lately, I think it is time to act on the project rather than still thinking about it. The whole concept behind Bug Tracking System is to ensure smooth and quality development of software. I would like to propose a preliminary project proposal for our organization ®.

Bug Tracking system will start with a login Screen. The login Users will consists of Testers, Developer, Team Leaders and Project Manager as their respective names. All the users will be given access to the system via their User IDs and passwords. The Bug tracking system is not limited to the testing of a Software System, it can also be utilized for proof reading the document. In that case, the Document Author can be termed as Developer and the Proof Reader can be termed as Tester.

Each of the users can file the Bug. Once the Bug is filed, the default state given to the bug is Open. (please see states of bug later in this document for further clarification). The bug could be filed along with its components explained below:

Bug Components

  • Bug ID: Usually the Bug identification number (It will help to keep track of the dupe entries)
  • Operating System: Example includes Windows 98, Win XP or Windows 2000. The Operating System on which the testing is performed.
  • Project ID: based on the assumption that human being cannot do multi tasking and they cannot test multiple projects at one time, it is a better idea to insert the option of Project ID at the time of Login. Alternatively the project ID can be entered when entering Bug details allowing the Bug entries to be made for multiple projects.
  • Form ID: Self Explanatory. It can be coupled with the Form Name as well.
  • Bug Description: A Short description of the bug which will help the user to search. Although the search is not limited to this field.
  • Severity Level: (4 Level Matrix that I have discussed in my previous testing report) Damage, Rare but not devastating, Annoying and Harmless. It can be made more meaningful to the developers using scales such as High, Medium and Low.
  • Steps to Reproduce: The numbered steps describing the how to reproduce the bug. This field has to have the potential to be verbose.
  • Categorize: The bugs can be categorized such as GUI bugs, Integration Bug, Unit Test Bug, etcetera.
  • Testing Type: The classification of test type, that is, Unit Test, GUI Test, Black Box Test, Clear (White) Box test, etcetera.
  • Web Browser: If a web site is being tested, then the name of Web Browser becomes an indispensable information for the identification of the bug.
  • Developer Assigned: This field indicates the bug has been assigned to which developer for the task of fixing. This field can be left blank or it can be left unassigned. Later, some one from the management, either Project Manager or Team Leader might assign the bug to the appropriate developer.
  • History: The Bug Log in other words. A complete bug log in read-only mode, details can include when the bug is filed, changes of bug states, and the bug assignments to developer. This should be coupled with the date and time when a particular event is performed.

Status of Bug

  • Fix: The state when the developer has fixed the error. From that point onwards, the bug will be transferred to the Tester, Team Leader or Project Manager. They could either verify it (if they find it fixed) or Reopen or Re Pop it (if they think it is not properly fixed.)
  • Defer: A bug will be deferred when it is not necessary for it to be fixed or corrected and it can be postponed for future removal due to some other serious bugs.
  • Dupe: A developer or a tester can indicate that the bug is duplicate, that is, the bug has been reported before. The relevant duplicate bug is also referenced.
  • Need More Information (NMI): If the developer does not understand or cannot find the bug then this would be the appropriate status of the bug.
  • Not Reproducible (NREP): Supplement to the above status except for the fact that the developer cannot find the bug.
  • Not A Bug (NAB): This status is introduced for the scenarios where there is special need, which the developer knows about, or in the view of developer, it is a feature.
  • Working as Desired (WAD): Supplement to point made above.

Since the advantages of web based application outweigh the desktop applications in terms of users accessing the application from different terminals, I would like to propose that it would be a better idea to develop this bug tracking system on web based technology such as ASP, JSP rather than desktop technology. I would also like to propose the use of Structured Systems approach for this Project since this system would definitely be upgrading to some advanced features such as emailing to notifications of bugs to Project Managers, Team Leaders, etcetera. In that case, it would be better if this system is developed with proper documentation standards, design methodology, and proper supervision.

 

Salman, Khwaja.

Technical Writer / SQA Engineer.
<Name with held> Private Limited.

Hosted by www.Geocities.ws

1