Team lead run team checklist - quality-manager/onboarding GitHub Wiki

Activities

Triaging Defects:

Checklist for triaging defects

  1. Do a through read on the defect description. Check for:
  • Duplicated defects
  • Defects that are WAD
  • Defects with buggy description or not following the defect template, ask the creator for clarification. Close the defect as “Finished troubleshooting” if they don’t respond in a couple of hours, when they update we can reopen if needed.
  1. If the defect is in your area of knowledge or the UI, try to reproduce in 703 and 702+ systems, include any extra findings (this also help us determine if the defect is a user error, for example). If the defect is totally outside your area of expertise, ask the owner of the defect to do a quick assessment.
  2. Assign the correct owner. This is the most tricky part, things to consider when choosing an owner for a defect:
  • If this is clearly under the area of expertise of the person (see the ETM Development Team).
  • Load balancing. If someone has already a big load of defects, we can assign to someone else (if the defect is not too complex or easy to figure out) As we don’t have enough resources, it’s important to choose the appropriate owner, we don’t want to assign defects to owners that don’t know that area because we will have the risk of them overspending time on said defect.
  1. Set the appropriate fields:
  • Verify the Summary and description are correct
  • Set the appropriate severity:
  • Set the defect to “Triage”
  • Based on your findings from (2), set the “Planned for” to the correct sprint.
    • Per 7.0.3 Sprint 18, "planned for" for severity 1, severity 2 and APAR defects should be set to current sprint. Other defects can be planned for backlog and the defect owner needs to change the "planned for" to the current sprint when they start working on the defect.
  • Set the right priority. Almost all defects should be set to priority high, unless they are minor hindrances.
  • Verify the How found and Regression (in case this applies) are properly set.
  • Set the “Filed against” to the appropriate category.

Things to consider for Lead approval

  1. Read the defect description and assure you understand the problem

  2. Check at the resolution tab:

  • Is the content clear?
  • Check for any missing points, for example, is the problem properly covered in the explanation + the solution?
  1. What kind of tests were done to verify that the fix works?
  • This includes, but is not limited to manual testing, Running JUnits
  • Assure the verification steps are properly explained
  • Assure tests were properly ran, for example, if a change is happening on the REST API, ask developer to run Smoke tests or the whole set depending the change. If there is a change in the OSLC API, ask to run the OSLC API (CM enabled & disabled if necessary)
  • Assure that for any server-side change, at the very least, the RQM_LITs JUnits are run.
  1. Code review
  • Review the code as you would do for any other of your previous reviews. i.e.: Are all code paths covered? check for nulls, overused data structures, etc.
  • Look at the big picture, for example: Are there any other areas that might be affected? (i.e. performance)
  • Verify for unused imports.
  • Is the code risky?
    • If this code is really long for a fix, shall we rethink the fix?
      • If the code is too complex.
      • If developer is unsure that a certain scenario is being covered
  • Ask questions if you don’t understand the code or if something is unclear
  • Bring any other reviewers if this is not your area of expertise.
  1. Review defect links
  • Verify Tracked elsewhere, depends on, resolved by, etc, are properly set

  1. Check for translations

    • Assure if there are any new/modified strings that they are reviewed by UA team

  2. Administrative:

    • Is Found in properly set?
      • Last known release this didn't work
    • Is How found properly set?
      • Special attention for FVT
    • Is Regression from properly set?
      • If regression is set, assure the Regression from field is set to sprint or release where this last worked AND depends On link must be set to the RFE/enhancement/plan item/story/task/defect that introduced the regression.
    • Is Affects automation properly set?
      • UI changes that modify structures in the screen (Consult with the ETM FVT Team Lead)
    • Is Filed against properly set?
      • Set the correct category, for example, Common components/Web UI for defects affecting common widgets. Be sure to double check if this is a feature defect, if this is the case it should be properly marked as "Feature".
    • Is Planned for properly set? (702+)
      • 702+/703 (not 702)
    • Is Translation set?
      • If there were changes to strings and Translation is set to TVT Test case Not required, inquire why.

  3. APAR

    • If this defect is an APAR, do we need any information for backporting this defect?
      • Assure Backport information is properly set in the APAR information tab, clearly indicating when something can't be backported or the backporting implications.

  4. For Forward ports: