Lecture 8 - Bug Tracking -> Quick Intro -> The Bug Tracking System -> Bug Tracking Procedure -> Quick Closing Note about BTS and BTP -> Lecture Recap -> Questions & Exercises1. The fact that a bug has been discovered has no practical value until we share information about that bug.
2. All found bugs must be filed into the BTS.
3. A bug can be filed by anyone who has a BTS account and bug filing privileges.
4. There are 2 stages of bug regression:
a. Verify that bug was really fixed (if bug was really fixed, you can close the bug right away).
b. Check to see if the process of fixing the bug has introduced new bugs.
5. On the one hand, the BTS is an infrastructure that enables us to
– create
– store
– view
– modify
information about bugs.
On the other hand, the BTS is a communication medium for SDLC participants.
6. The process that begins with filing a bug into the Bug Tracking System is called the Bug Tracking Process.
7. BTS Attributes:
>ID is the unique identifier of each BTS bug record.
>Summary is a brief synopsis of the problem.
>Description is a detailed description of the problem.
>Attachment is needed to illustrate the bug (e.g., with a screen shot)
>Submitted by is the alias of person who has filed the bug.
>Date is the date when the bug was filed.
>Assigned to is required to specify the bug owner. Every open bug ALWAYS has a bug owner. The bug owner is the person responsible for next step in resolving the bug.
>Assigned by is the alias of the last person who assigned the bug (i.e., whoever selected the new bug owner from the “Assigned to” drop-down menu).
>Verifier is the person who must verify the bug once it’s fixed.
>Component is the area where the bug was found.
>Found on is the environment where bug was found.
>Version is the version of the software where the bug was found.
>Build is the build number of the software where the bug was found.
>DB is the DB schema version of the software where the bug was found.
>Comments are needed to provide additional info about the bug or about actions associated with the bug, etc.
>Severity is about the bug’s impact on the software.
>Priority is about the bug’s impact on the company’s business.
>Also notify can be used to add other individual(s) who should be notified about the fact of the bug filing and about changes to the bug.
>Change history is needed to keep track of any change that happens to the bug.
>Type is needed to specify the bug type: “Bug” or “Feature Request”.
>Status tells us whether the bug is open or closed. If the bug reemerges, we re-open it.
>Resolution is needed to specify the stages of a bug’s life.
8. Bug Resolutions (explanations are given with the assumption that bug report has Type “Bug”):
>Reported: A bug was filed, but the developer to fix it has not been assigned.
>Assigned: Assigned developer must start bug investigation.
>Fix in progress: The developer is fixing the bug.
>Fixed: The bug was fixed, but the bug fix hasn’t been verified yet.
>Fix is verified: The bug fix has been verified.
>Verification failed: The bug fix verification failed; i.e., bug is reproducible after the bug fix.
>Cannot reproduce: The developer cannot reproduce the bug.
>Duplicate: The bug is a duplicate of another bug.
>Not a bug: The bug is not considered to represent a problem (i.e., a deviation of actual from expected).
>3rd party bug: The bug is in 3rd party software.
>No longer applicable: The bug doesn’t have any meaning anymore.
– Remember the principle of effective simplicity when you set up the BTS and/or introduce the BTP. Next ->
Lecture 8 - Bug Tracking -> Quick Intro -> The Bug Tracking System -> Bug Tracking Procedure -> Quick Closing Note about BTS and BTP -> Lecture Recap -> Questions & Exercises
