Useful Links

• Run Team WIKI
• Run Team Dashboard

Run Team Member Tasks

• Severity/Priority Order:
  • S1-Blocker > S1-Critical > S2-Major > S3-Normal/P1-High > S3-Normal/P2-Medium > S3-Normal/P3-Low
• If no unresolved defects are owned contact the Run Team Lead.
• Fixes should include tests to cover the fixed functionality. Members should use their judgement to determine if creating the tests are feasible and cost-effective.
  • Code review response times
    • S1-Blocker and S1-Critical - < 12 hours
    • S2-Major, S3-Normal, and S4-minor - < 24 hours
• When resolving a defect and it is unclear what to set the resolution state as contact a team lead or manager for guidance.

Lifecycle of a Defect

• When starting a defect
  1. Accept them from your Inbox to Current Work
  2. Set the "Estimate"
  3. Set the "Planned For" for the current milestone
  4. Set the "Status" to "In Progress"
• When working on the defect keep the "Time Spent" up to date.
• Always reproduce the defect. If it can not be reproduced then Resolve it appropriately.
• If a fix is created
  1. Make sure all relevant code to the fix are in changeset(s).
  2. Attach the associated changeset(s) to the defect.
  3. When you have completed the fix move to "In review".
  4. Request a code review. These should be conducted by other Run Team members if available. If not it can be conducted by anyone on the Run Team.
  5. Add one approved for the team leader and 1 review for code review.
  6. If the code review is rejected improve on your solution and request another review. Repeat this process until the code review is accepted.
• Delivering code
  1. After the defect has a accepted code review deliver the associated changeset(s)
  2. Change the state of the defect to Resolved.

Defect State Overall Picture

Defect Status States and Actions

Status	Description	Owner Actions on Entry to State	Notes
New	The initial state of a defect when it is raised.	The development owner should evaluate the defect - is it valid? is it a duplicate? Is enough information provided? If so they should close it as invalid, or a duplicate, or ask for further info and put it into 'Awaiting Information' state. Otherwise it should be put into 'Triaged' state.
Triaged	Defect considered "valid" by development, on the queue for investigation	Ensure the Planned For field correctly represents the intended value. The 'Owner' field should be unassigned unless immediate action is intended. Note that the pruning of invalid, duplicates etc should already have been carried out (see above) before entering this state).
In Progress	Defect under investigation	Ensure the 'Owner' field is the developer working on the defect.	In active investigation and fixing.
In Review	Defect under review	Your fix is ready for review
Resolved	Defect claimed fixed by Development, pending verification	Ensure the Planned For field is correct for the sprint the fix was delivered to.
Closed	Defect closed, the "Resolution" field gives further detail		e.g. Closed/Invalid, Closed/Duplicate, Closed/WAD, Closed/Verified etc
Reopened	Defect failed verification or has reoccurred	The Owner should examine the defect and move to another state, just as for a 'New' defect.
Awaiting Fix to Adopt	Awaiting a fix in a third party component that we will adopt.	Owner should monitor the third party defect and should move to 'In Progress' and adopt the fix, once it becomes available.	Used when we need a fix in a third party component, but that is not enough and we will need to make further changes to our code to fix the original problem.
Tracked Elsewhere	Awaiting a fix in a third party component that will cure this issue.	Owner should monitor the third party defect and should move to 'Resolved', once the component with the fix in it is included in the Nightly build.	Used when we need a fix in a third party component, and once that changed component is included, the original defect will be addressed.
Verified	The defect has been tested and verified to be fixed	Typically the owner does not resolve it to this state. Someone from the group who created the defect will change the defect to this state after they have tested it.

Defect Resolution States

Resolution	Meaning
Fixed	Defect has been resolved by the code in the attached changeset
Won't Fix	Although this is a defect, there are no plans to fix it (normally for cost reasons)
Duplicate	This defect is the same as a previously raised one, and this defect points at it. The reproduction steps need to be similar. Not just the symptoms. If the symptoms are the same but the reproduction steps are not then use the Fixed Indirectly resolution with a Resolved By link to the fixing work item.
Fixed Indirectly	The defect was addressed by a previously delivered fix and this defect specifies exactly which fix or code change addressed the defect. Ideally should include a link to the item/task that fixed the issue
Not Supported	Used where the defect involves a scenario or environment that is not supported
Resolved Elsewhere	The defect was due to an issue in third party code, but a fix has now been delivered into the codebase.
Works as designed	When it is not really a defect
Not enough information	When we can't reproduce after a reasonable investigation
Finished Troubleshooting	Defect required Development investigation, but was in fact an environmental/configuration issue, with no change to the product required.