Defect MgmtBugDay Bangkok 2009: Defect Management


Published on

Session: Defect Management
Event: BugDay Bangkok 2009
Venue: Sripatum University
Date: December 19th, 2009

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Defect MgmtBugDay Bangkok 2009: Defect Management

  1. 1. Defect Management
  2. 2. Background: Maysinee Nakmanee <ul><li>Re-engineering Projects-Banking </li></ul><ul><li>Center of Software Engineering </li></ul><ul><li>Teaching/Guest Speaker for public/private org. </li></ul><ul><li>Thompson-Reuters/Global Development </li></ul><ul><ul><li>Global configuration management tool </li></ul></ul><ul><ul><li>Global defect tracking tool </li></ul></ul><ul><li>(current) DSTi- IFDS Group </li></ul><ul><ul><li>International Financial Development Service </li></ul></ul>
  3. 3. What is defect? <ul><li>Something wrong in the system </li></ul><ul><li>Can we live in the “defect-free” world? </li></ul><ul><li>What people can do to prevent the defect? </li></ul>
  4. 4. Defect/Bug Types <ul><li>Mild - misspell output, lack of white space </li></ul><ul><li>Moderate - output may be misleading or redundant </li></ul><ul><li>Annoying - users need tricks to get system to work </li></ul><ul><li>Disturbing - refuses to handle legitimate transaction </li></ul><ul><li>Serious - looses track of transaction and its occurrence </li></ul><ul><li>Very serious - bug causes system to incorrect transaction </li></ul><ul><li>Extreme - problem limited to a few user or a few transaction type, frequent, and arbitrary </li></ul><ul><li>Intolerable -long term unrecoverable corruption of database, system shutdown may need to occur </li></ul><ul><li>Infectious - corrupts other systems, system that causes loss of life </li></ul>
  5. 5. Defect Management Process <ul><li>Refer to as “Incident Management Tools” </li></ul><ul><li>Prevent Defect </li></ul><ul><li>Find the defect as quickly as possible </li></ul><ul><li>Should be </li></ul><ul><ul><li>Impact analysis </li></ul></ul><ul><ul><li>Root-cause analysis </li></ul></ul><ul><ul><li>Improve the process </li></ul></ul>
  6. 6. Defect Reporting <ul><li>Defects are recorded for four major purpose </li></ul><ul><ul><li>Ensure defect is corrected </li></ul></ul><ul><ul><li>Report status of the application </li></ul></ul><ul><ul><li>Gather statistics used to develop defect expectation in future application </li></ul></ul><ul><ul><li>To improve the software development process </li></ul></ul>
  7. 7. Defect Severity vs. Priority <ul><li>Severity: Defect may be defined as one that causes data corruption or system crash, security violation. </li></ul><ul><li>Priority: The order in which defects should be fixed. It is more subjective as it may be based on input from users regarding which defects are most important, resources available, risks. </li></ul>
  8. 8. A sample defect tracking process I. Run Test II. Log Defects III. Investigate Defects <ul><li>IV. Defect Resolution Process </li></ul><ul><li>Priority the correction </li></ul><ul><li>Schedule the correction </li></ul><ul><li>Correct the defect </li></ul><ul><li>Report the resolution </li></ul>V. Report the resolution
  9. 10. “ Traceability”
  10. 11. Traceability of Requirement to Testing <ul><li>Traceable from </li></ul><ul><ul><li>Requirements </li></ul></ul><ul><ul><li>Planning </li></ul></ul><ul><ul><li>Development </li></ul></ul><ul><ul><li>Testing </li></ul></ul>
  11. 12. Testing Testing Unit Test System Test Regression Test Stabilization Test User Acceptance Test
  12. 14. Defect Information <ul><li>What is the defects </li></ul><ul><li>Who found </li></ul><ul><li>Who will fix </li></ul><ul><li>In which area </li></ul>
  13. 15. Defect Type <ul><li>When testers found the defects, we need to recheck first whether it is code issue or code related or not. </li></ul><ul><li>Sometimes, it may be defect from environment from data that has been conversed but not the code issue. </li></ul>
  14. 16. Root cause of defects <ul><li>The most important thing in defect management is to be able to identify the root cause of defect in order to prevent the future problem. </li></ul>
  15. 17. Priority of defects
  16. 18. Impacted Area <ul><li>Impact: Fix one part may affect to other parts. This may cause “Defective fix” defect. </li></ul><ul><li>Review of impacted area is the most important before any resolution </li></ul>
  17. 19. Fix Defects <ul><li>Developer needs to provide </li></ul><ul><ul><li>Resolution </li></ul></ul><ul><ul><li>When to finish the fix </li></ul></ul><ul><ul><li>Impacted area </li></ul></ul><ul><ul><li>Root cause of the defect </li></ul></ul><ul><ul><li>Unit test result of the fix </li></ul></ul><ul><li>Tester needs to </li></ul><ul><ul><li>Re-assure the solution </li></ul></ul><ul><ul><li>Re-test and Close the defect </li></ul></ul>
  18. 20. Fix Defects <ul><li>Would that be possible that some defects have never been fixed? </li></ul><ul><li>What will affect to the system? </li></ul><ul><li>Why we do that? </li></ul>
  19. 21. Defect Metrics
  20. 22. Defects Metrics <ul><li>Phase Injected </li></ul><ul><li>Phase found </li></ul><ul><li>How many priority defects </li></ul><ul><li>How quick we can resolve the defects </li></ul><ul><li>Root cause of the defects </li></ul><ul><li>How long a defect has been openned </li></ul>
  21. 23. Defect Management <ul><li>Collaboration between all parties </li></ul><ul><ul><li>Developers </li></ul></ul><ul><ul><li>Testes </li></ul></ul><ul><ul><li>Business Analyst </li></ul></ul><ul><ul><li>System Analyst </li></ul></ul><ul><li>Sometimes, Fix is a nice to have but may not be a need to do </li></ul>
  22. 24. Defects as requirements <ul><li>Collection of defects from previous release/version can be come requirements for next release. </li></ul><ul><ul><li>Production issue defects </li></ul></ul><ul><ul><li>Minor defects </li></ul></ul>
  23. 25. Summary <ul><li>Defect management is the most important process that all stakeholders need to aware of. </li></ul><ul><li>Considering defect information to support defect management. </li></ul>