Bug trackingworkflow
-
Upload
petro-porchuk -
Category
Technology
-
view
1.322 -
download
0
description
Transcript of Bug trackingworkflow
Petro Porchuk03/29/2011
TFS Work Items Workflow
?
Active
ClosedResolved
Do Nothing
The Goal is – to clarify
Agenda
Roles Email Notifications Work Item Types User Story Workflow Prioritizing Bugs Bug Workflow Task Workflow Q&A
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
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.
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
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)
Acceptance tests fail
At least:
1 * Critical Issue OR
1 * High Issue OR
N * Medium Issues, where N is too many
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
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
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
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)
What we still lack?
WHO IS DOING WHAT AT THE MOMENT
?IS THE FIX/NEW CODE AVAILABLE FOR ME TO TEST
(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 ->
Summary
We need Work Item STATES for following the right Development Process. Email notifications provide immediate
heads up
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
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
Summary
Use appropriate REASON while transferring Work Items through the workflow
Summary
Do not hesitate to put comments in the History section for cases there are not relevant REASON as well as for other
cases
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
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