Bug trackingworkflow

22
Petro Porchuk 03/29/2011 TFS Work Items Workflow

description

 

Transcript of Bug trackingworkflow

Page 1: Bug trackingworkflow

Petro Porchuk03/29/2011

TFS Work Items Workflow

Page 2: Bug trackingworkflow

?

Active

ClosedResolved

Do Nothing

Page 3: Bug trackingworkflow

The Goal is – to clarify

Page 4: Bug trackingworkflow

Agenda

Roles Email Notifications Work Item Types User Story Workflow Prioritizing Bugs Bug Workflow Task Workflow Q&A

Page 5: Bug trackingworkflow

Roles

Manager/Admin – unlimited permissions

DEV – Developer– Create Tasks (Create Bugs, Create User Stories)– Resolve Bugs, User Stories– Close Tasks

QC – Quality Control Engineer– Create Bugs, Tasks (Create User Stories)– Close Bugs, User Stories, Tasks– Reopen Bugs, User Stories Tasks

USER – End User Representative– Create Problem Reports– Close Problem Reports– Reopen Problem Reports

Page 6: Bug trackingworkflow

Email Notifications

DEV– Active US/Bug has been assigned

to. (New, Reopened, Edited).– Worked on US/Bug has been

closed.

QC– Active US/Bug has been moved to

Resolved and Assigned to.– Worked on US/Bug has been

closed.

We need email notifications each time a work item is being moved through the workflow to quickly know

what to do and don’t bother one another with stupid questions like: “Are you done with the story, so I

can test?”, “Have you done with testing, how it went?”.

We need to use the tool we have for that – TFS.

Page 7: Bug trackingworkflow

Work Item Types

User Story - one or more sentences in the everyday or business language of the end user that

captures what the user wants to achieve. Before a user story is to be implemented, an appropriate acceptance procedure must be written by the customer to ensure by testing or otherwise determine whether the goals of the user story have been fulfilled.

Bug - a program defect, which is usually found and described as a failure (deviation

between actual and expected behavior). Usually filed by QA.

Task - an activity that needs to be accomplished within a defined period of time. Is usually

a sub-item of a Bug, User Story

Problem Report – an unverified report, usually filed by PM or user. After positive verification a bug

report is created. Bug report changes are automatically reflected in the problem report

Page 8: Bug trackingworkflow

User Story Workflow

Active (assigned)

Resolved

Closed

Code complete and unit tests pass Build is available for QC

(DEV)

Acceptance tests pass

(QC)

Acceptance tests fail*(QC)

Reintroduced in Scope/Closed in Error

(QC)

Active (New)

Assign (Admin)

Unassign (Admin)

Resolved (assigned)

Assign (DEV)

Unassign (DEV)

Email to DEV

Email to QC

Email to DEV & QC involved

Closed in Error(QC)

Rejected/Out of Scope/ Abandoned(QC, Admin, DEV)

Page 9: Bug trackingworkflow

Acceptance tests fail

At least:

1 * Critical Issue OR

1 * High Issue OR

N * Medium Issues, where N is too many

Page 10: Bug trackingworkflow

Prioritizing Bugs

Priority (When it should be fixed?)

The level of (business) importance assigned to an item, e.g. defect.

Severity (What it affects?)

The degree of impact that a defect has on the development or operation of a component or system.

Priority Description Defined By

1 The bug is Critical for business needs. Must be fixed ASAP

Bug Reporter

2 Very important issue to be fixed

Bug Reporter

3 Highly appreciated to have

Bug Reporter

4 Nice to have Bug Reporter

Severity Description Example Defined By

1 (Critical) An Absolute Blocker. Unable to Start or Use Application. Crash.

Bug Reporter

2 (High) Serious Failure. Direct argument against the Acceptance Criteria

Unable to Create new row. Unable to edit existing rows. Data loss.

Bug Reporter

3 (Medium) Regular bug. Affects very few of potential users. Not blocking anything

Keyboard shortcuts do not work. Validation missing

Bug Reporter

4 (Low) Minor issue, not affecting anyone at all, just annoying

Cosmetic UI issues, grammar errors

Bug Reporter

Page 11: Bug trackingworkflow

Prioritizing Items

Stack Rank (What you shall work on first)

-is the traditional method Product Owners use to rank/prioritize their product backlog items.

The lower the stack rank the higher the priority the work item is

Page 12: Bug trackingworkflow

Bug Workflow

Active (assigned)

Resolved

Closed

As Designed/Cannot Reproduce/ Deferred/Duplicate/Obsolete

(DEV) Fixed(DEV)

Verified (QC)

Not fixed/Test Failed(QC)

Regression/Reactivated(QC)

Active (New)

Assign (QC)

Unassign (QC)

Resolved (assigned)

Assign (DEV)

Unassign (DEV)

Email to DEV

Email to QC

Email to DEV & QC involved

Page 13: Bug trackingworkflow

Task Workflow

Active (assigned)

Closed

Completed (QC, DEV, Admin)

Reactivated(QC, DEV, Admin)

Active (New)

Assign (QC, Admin, DEV)

Unassign(QC, Admin, DEV)

Deferred, Cut, Obsolete

(QC, DEV, Admin)

Page 14: Bug trackingworkflow

What we still lack?

WHO IS DOING WHAT AT THE MOMENT

?IS THE FIX/NEW CODE AVAILABLE FOR ME TO TEST

Page 15: Bug trackingworkflow

(Proposed) Bug Workflow

In Progress

Pending Build

Closed

As Designed/Cannot Reproduce/ Deferred/Duplicate/Obsolete

(DEV) Fixed(Work done by DEV)

(DEV)

Verified (QC)

Not fixed/Test Failed(QC)

Regression/Reactivated(QC)

Active (assigned)

Start Work(DEV)

Stop Work(DEV)

Resolved (assigned)

Build Available (TFS)

Email to DEV

Email to QC

Email to DEV & QC involved

Email to QC

Useful for Managers ->

Useful for QC ->

Page 16: Bug trackingworkflow

Summary

We need Work Item STATES for following the right Development Process. Email notifications provide immediate

heads up

Page 17: Bug trackingworkflow

Summary

Each particular state means some work needs to be done by relevant department:

– An Item mustn’t be RESOLVED if there some known developer work still needs to be done. Existing Critical bugs are the case

– An Item mustn’t be CLOSED if QC has something to test

Page 18: Bug trackingworkflow

Summary

The only reason a Work Item is not being transferred to the next state – is progress on it. If you are done with it,

immediately move it forward with the STATE

Page 19: Bug trackingworkflow

Summary

Use appropriate REASON while transferring Work Items through the workflow

Page 20: Bug trackingworkflow

Summary

Do not hesitate to put comments in the History section for cases there are not relevant REASON as well as for other

cases

Page 21: Bug trackingworkflow

Q&A

Q: What if I have a reason, which is not included in the Reason Dropdown?A: Feel free to select the most suitable one and put your comments in the History field. Don’t be miserly

for comments.

Q: (DEV) What if I want to pass to QC non-finished Story to test?A: Fire away! But don’t make it RESOLVED. QC won’t file bugs – only inform you about the Smoke Test

results. It’s your deal. Beneficial for close collaboration. Should not be a common practice.

Q: (DEV) When shall I make an Item RESOLVED?A: When you complete all the work on it, and (theoretically) it should go on Production, if no critical

bugs. Also when QC is able to access the test object.

Q: (QC) What if I found S1/S2 issue, and developer is asking me not to reopen the Story for several minutes, the fix is being prepared?

A: Go for it, but if you really going to have the fixed build in 1-2 hours. If it lasts longer – reopen the Item with the issue linked.

Q: (ANYONE) Would like to introduce new feature.A: Make a list of. Come up with the proposal in the Status Meetings. Introduce “Improvement Iteration”

Q: Parent -> Child Stories in the BacklogA: TODO

Page 22: Bug trackingworkflow

Thank You!

Copyright © 2011 SoftServe, Inc.

Contacts

Europe Headquarters 52 V. Velykoho Str.Lviv 79053, Ukraine

Tel: +380-32-240-9090Fax: +380-32-240-9080

E-mail: [email protected]: www.softserveinc.com

US Headquarters12800 University Drive, Suite 250Fort Myers, FL 33907, USA

Tel: 239-690-3111 Fax: 239-690-3116