Docstoc

Bug Tracking of power point

Document Sample
Bug Tracking of power point Powered By Docstoc
					Bug Tracking Systems

Topic Organization
1. Bug & Basic Terminology

2. Evaluation of Bug Tracking System 3. Bug Reporting and Tracking- WWWH • What is Bug Reporting and Tracking? • Who are involved in Bug Reporting and Tracking? • Why to Report and Track a Bug? • How To Report and Track a Bug?  Bug Life cycle-Steps  Bug Tracking Systems 4. Effective Bug Reporting
5. Perfect Bug Tracking
Confidential 2

Topic 1

Bug & Basic Terminology

Confidential

3

Bug & Basic Terminology
Error: Deviation for actual and the expected/theoretical value. It refers to the discrepancy between a computed, observed, or measured value and the true, specified, or theoretically correct value. That is, error refers to the difference between the actual output of a software and the correct output.

Bug: An Error found in the development environment before the product is shipped to the customer.
Defect: An Error found in the product itself after it is shipped to the customer. Failure: A system is said to have a failure if the service it delivers to the user deviates from compliance with the system specification for a specified period of time.

Enhancement: An improvement to an existing feature.
Feature: An addition to the software to add a piece of functionality that does not yet exist.

Patch: A section of code to be applied or attached to existing software, often to fix a defect.

Confidential

4

Topic 2

Bug Reporting & Tracking WWWH
What? Who? Why?How?

Confidential

5

WWWH
What is Bug Reporting and Tracking? Who are involved in that? Why Bug Reporting and Tracking? How to Track a Bug?

Confidential

6

What is Bug Reporting and Tracking?
Bug Reporting :
A person who uses a product Reports a Bug/Malfunctioning ..etc to a person who developed the product

Bug Tracking :

Managing and Reviewing a bug and its status

Bug Tracking System :

This is a system designed especially to manage software problems, enhancement, change request during software development life cycle.

Confidential

7

Who are involved in that?
Customer/Reporter: The Customer role is the person who files the bug report. It may be a real end user customer, or it may be a QA Engineer, or an IT project team member. In all cases, the duties are the same. Programmer: The Programmer is the role taken by the person who is assigned to fix and regression test to make sure the fix didn't break other features in the system.

Tester: The role of Tester is to verify the fix and validate it against the bug reported
Dispatcher/Review Team: The Dispatcher has the role of setting priorities and assigning bugs to be worked on, then following up on work. The Dispatcher can coordinate the life cycle events between various other roles. The Dispatcher can be a Systems Analyst, Developer, etc.

Confidential

8

Why Bug Reporting and Tracking?
Why Bug Reporting ?
• Malfunctioning of the application • Missing Functionalities
• To enhance the existing features of an application (Change request) • To add the extra features to an application

Confidential

9

Why Bug Reporting and Tracking?
Why Bug Tracking ? • Milestones - Triage Process
• Severity

• Priority

Confidential

10

Milestone - Triage Process
Milestones Milestones are planned events when certain planned deliverables are provided. These are achievable short term Targets at which it is possible to evaluate progress towards a final Objective. Each output of one milestone is marked as input to next milestone.

Triage Process -

This is the process by which “new” defects are reviewed

and action taken. A “new” defect will be reviewed by the “Review Team” The “Review Team” can take a number of actions that result in changes to either the STATUS and/or the Assigned-To field.
1. Defer: If the bug is a valid bug but it won’t be fixed in the near future 2. Assign: If the bug is something that needs attention then the Assigned-To field will be set to a named person. 3. Close: If the “Review Team” decide the bug is not a bug

Confidential

11

Severity
This field describes the impact of a bug. The submitter of the bug should consider carefully their view of the bug severity, i.e. the impact to them as the end user.
Blocker

Blocks development and/or testing work
crashes, loss of data, severe memory leak major loss of function
Minor loss of function. Unfriendly behavior that is hindering, but workable, for the user or service

Critical

Major

Normal

Minor

Minor loss of function. Unfriendly behavior that is merely annoying to the user

Trivial

cosmetic problem like misspelled words or misaligned text
Request for enhancement

Enhancement
Note:

The default severity is Normal.
Confidential 12

Priority
Priority is used to organize the work.This field describes the importance and order in which a bug should be fixed. The field only takes meaning when owner of the bug
P1 P2
Fix in next build Fix as soon as possible Fix before next release

P3 P4 P5

Fix if time allows Unlikely to be fixed

Default priority for new defects is set at P3.

Confidential

13

How to Track a Bug?

Bug States/Life Cycle Bug Tracking Systems

Confidential

14

Bug Life Cycle-Steps
As defects move through the system they are given various states. At each state there are a number of possible transitions to other states

Confidential

15

Bug Life Cycle-Steps
NEW  ASSIGNED  RESOLVED  VERIFIED  CLOSED  REOPENED
NEW Recently added
to ASSIGNED by acceptance to RESOLVED by analysis and maybe fixing to NEW by reassignment ASSIGNED The owner, i.e. the person referenced by Assigned-To has accepted this bug as something they need to work on to NEW by reassignment to RESOLVED by analysis and maybe fixing REOPENED Was once resolved but has been reopened to NEW by reassignment to ASSIGNED by acceptance to RESOLVED by analysis and maybe fixing

Confidential

16

Bug Life Cycle-Steps
NEW  ASSIGNED  RESOLVED  VERIFIED  CLOSED  REOPENED
RESOLVED Has been resolved (e.g. fixed, deemed unfixable, etc.
See "resolution" column)
to REOPENED by reopening to VERIFIED by verification to CLOSED by closing

VERIFIED The resolution has been approved by QA
to CLOSED when the product ships to REOPENED by reopening

CLOSED Over and done with
to REOPENED by reopening

Confidential

17

Bug Life Cycle-Resolutions
Resolution Meaning

FIXED INVALID
WONTFIX LATER

The bug has been fixed. The problem described is not a bug.
This bug will never be fixed. This bug will not be fixed in this version.

REMIND

This bug probably won't be fixed in this version.

DUPLICATE WORKSFORME MOVED

This is a duplicate of an existing bug This bug could not be reproduced. This bug has been moved to another database.

Confidential

18

Bug Life Cycle-Resolutions
Gemini Nomenclature
New Analysis - Prod Mgmt Analysis - QA Analysis - Dev Review Targeted Development Code Complete Deployed QA Rejected by Test Verified UAT Accepted Returned to Submitter Deferred Closed
Confidential

New Feature Change Request Problem Report Task

Type

Status

Currently Unresolved Cannot Reproduce Not Needed Work to Completion Works as Designed

Resolution

19

Better Approach

Confidential

20

Bug Tracking Systems (tools)

  

Web Based Client-Server Based Bug Trackers Integrated with version control

Confidential

21

Topic 3

Effective Bug Reporting

Confidential

22

Effective Bug Reporting
Keep bug reporting simple: Don't make bug reporting complicated by requiring
entry of more data than is really necessary

Describe how to reproduce bugs: A bug report should include a step-by-step
description on how to reproduce the bug (or replication information)

Record how bugs are detected: Report all the facts-Allow them to reproduce
the bug

Write bug reports immediately : the longer you wait between finding the

problem and reporting it, the more likely it is the description will be incomplete, the problem not reproducible, or simply forgotten.

Writing a one-line report summary : Writing the Bug's report title is an art.
You must master it (the same should be related to bug you are reporting)

Don't use the same summary: For two different reports, even if they are similar
don’t use similar summary

Consult your peer member: Before writing a bug consult your peer team member (if the same has already been reported).

Confidential

23

The Perfect Bug tracking

• Make a build of the software daily
• Use a process to handle bug reports

• Resolution field
• Handle feature requests separately

Confidential

24

Questions

Confidential

25

Thanks You

Confidential

26


				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:439
posted:1/8/2008
language:English
pages:26