Download to read offline
Uploaded byVolodymyr Melnyk
Quality management
The document discusses quality management for project management. It defines quality, describes quality management goals like customer satisfaction and continuous improvement, and explains key quality management processes like quality planning, quality assurance, and quality control. Quality planning involves activities to develop quality management documentation. Quality assurance ensures processes are adequate, while quality control evaluates work products through inspections and testing to find defects. The document emphasizes the importance of metrics for quality assurance to track testing progress, defects, and determine release readiness.
Quality management
- 1. Quality Management forPM Volodymyr Melnyk
- 2. What Is Quality? •Oxford American Dictionary • a degree or level of excellence • American Society for Quality • totality of features and characteristics that satisfy needs without deficiencies • PMBoK • the degree to which a set of inherent characteristics fulfill requirements
- 3. Definition of Quality • Conformance to the requirements • Fitness for use • Fitness for purpose • Customer satisfaction
- 4. Quality Management Goals • Customer Satisfaction • Prevention over Inspection • Continuous Improvement • Management Responsibility
- 5. Cost of Quality(COQ) • Cost of conformance – Prevention costs – Appraisal costs • Cost of Non‐conformance – Internal failure – External failure
- 6. Quality Management Processes •Quality Planning • Quality Assurance • Quality Control
- 7. Quality Planning • Activities – Project documentation analysis – Flowcharting – Brainstorming – Others • Outputs – Quality Management Plan – Quality Metrics – Quality Checklists – Project Documentation Updates
- 8. Quality Assurance • Input – Metrics – Quality Control Measurements • Activities – Quality Audits – Process Analysis • Output – Organization Process Assets Updates – Change Requests – Project Documentation Updates
- 9. Quality Control • Input – Deliverables – Metrics and Checklists • Activities – Inspections – Others • Outputs – Validated Deliverables – Quality Control Measurements (and other reports) – Change request – Others
- 10. •Quality Control: Aset of activities designed to evaluate a developed work product. •Quality process of executing a system with the intent of that the development and/or maintenance process is adequate to ensure a system will meet its objectives. •Testing: TheAssurance: A set of activities designed to ensure finding defects. •Quality Control: A set of activities designed to evaluate a developed work product. •Quality process of executing a system with the intent of that the development and/or maintenance process is adequate to ensure a system will meet its objectives. •Testing: TheAssurance: A set of activities designed to ensure finding defects. •Quality Control: A set of activities designed to evaluate a developed work product. •Testing: The process of executing a system with the intent of finding defects. QA vs QC vs Testing • Quality Assurance – process oriented • Quality Control – product oriented • Testing – The process of executing a system with the intent of finding defects – Product oriented
- 11. Why Metrics forQA? 1. How do you determine quality and progress of testing? 2. How much testing is completed? 3. How much more time is needed for release? 4. How much time needed to fix defects? 5. How many Days needed for release? 6. How many defects that will be reported by customers? 7. Do you know how to prevent defects rather than finding and fixing them? Do you have answers?
- 12. Why Metrics forQA? - Summary • When to make the release? • What to release? • Are we releasing the product with known quality?
- 13.
- 14. Test Case ExecutionStatistics 100% 90% 80% 70% 60% Blocked 50% Not Run 40% Fail 30% Pass 20% 10% 0% 1 2 3 4 5 6 7 8 10 11 12
- 15. Defects Trend 140 120 100 80 60 40 20 0 0 2 4 6 8 10 12 14 16 Find Defects Fixed Defects Outstanding Defects Severity Outstanding Defects
- 19.
- 20. Defect Cause DistributionChart Third Party 2% Others 8% Requirement 17% Change Request 23% Design 15% Feature Request 5% Code 30%
- 24.
- 26. Time to Fixa Defect TFD = (Time spent to Investigate and Fix Defects)/(Number of resolved defects) Provides an indication of the maintainability of the product and can be used to estimate projected maintenance costs.
- 29. Closed Defect Distribution Next Release 2% Others 10% Fixed 27% Will not fix 23% Duplicate 17% As per design 8% Not reproducable 13%
- 30.
- 34. Scope Changes • Scope creep • Indicates requirements stability or volatility • Indicates process stability Scope Changes Ratio = the number of changed items in the test scope / the total number of items
- 35. Thank you! Q&A
Editor's Notes
- #4 Conformance to the requirements. (Does the product or service conform to the requirements?) Fitness for use. (Is the product or service capable of being used?) Fitness for purpose. (Does the product or service meet its intended purpose?) Customer satisfaction. (Does the product or service meet the customer's expectations?)
- #7 QP - Identifying which quality standards are relevant to the project and determining how to satisfy them.QA - Applying the planned systematic quality activities to ensure that project employs all processes needed to meet requirementsQC -
- #8 The process of identifying quality requirements and standards, and documenting how to demonstrate the complianceQuality planning in parallel with other project planning
- #12 Testing is penultimate cycle of product release ---Determining quality and progress of testing thus is very importantHow much testing is completed can be measured if you know how much total testing is neededHow much more time is needed for release (e.g) Days needed to complete testing = total test cases yet to be executed / test case execution productivityHow much time needed to fix defects (e.g) The defect trend gives a rough estimate of defects that will come in future. Metrics helps in predicting the number of defects that can be found in future test cycles (e.g) Total days needed for defect fixes = (Outstanding defects yet to be fixed + Defects that can be found in future test cycles) / defect fixing capabilityDays needed for release = Max of (days needed for testing, days needed for defect fixes)Days needed for release = Max of (Days needed for testing, (Days needed for defect fixes + Days needed for regressing outstanding defect fixes))
- #13 When to make the releaseWhat to release–Based on defect density across modules, their importance to customers and impact analysis of those defects, scope of the product can be decided to release the product on time. Metrics help in making this decision. Are we releasing the product with known quality? –The idea of metrics is not only for meeting the date but also to know the quality of product and ascertaining the decision on whether we are releasing the product with the known quality and whether it will function in predictable way in the field.
- #15 Increase in pass % indicate, quality of product improvingDecrease in Blocked % indicate, tests can progress wellReduced % in fail, is requirement for a releaseNot run % should be Zero for the release; final week should have only Pass and Fail %
- #17 Provides indications about the quality of the product under test. High-severity defects mean low product quality, and vice versa. At the end of this phase, this information is useful to make the release decision based on the number of defects and their severity levels.
- #18 Provides a direct measurement of the quality of the product—specifically, reliability, fault tolerance and stability.
- #19 Both “large defects” and “large number of small defects” affect the product release
- #21 Knowing the causes (Why a defect happened) of defects help in finding more defects and also in preventing such defects early
- #22 Knowing the components producing more defects help in defect fix plan and in deciding what to release
- #23 This metric indicates the quality of the product under test. It can be used as a basis for estimating defects to be addressed in the next phase or the next version.
- #24 DRE is a measure to detect defects before delivery and is the percentage of bugs eliminated by reviews, inspections, tests etc. Indicates the efficiency of defect removal methods, as well as indirect measurement of the quality of the product.
- #26 The total number of defects found in a given time period/phase/test type that resulted in software or documentation modifications. Only accepted defects that resulted in modifying the software or the documentation are counted.
- #27 Effort required to resolve a defect (diagnosis and correction).
- #29 This metric is an indication of the completeness of the testing. It does not indicate anything about the effectiveness of the testing. This can be used as a criterion to stop testing.Coverage could be with respect to requirements, functional topic list, business flows, use cases, etc. It can be calculated based on the number of items that were covered vs. the total number of items.
- #30 Fixed in closed is a good metric to have for both DEV & test teamsDuplicate to be avoided (<5%)Not reproducible defects may reappear again; need to be carefulDefects moving to next release needs to be with in certain band (3-6%)
- #32 The effort spent in testing, in relation to the effort spent in the development activities, will give us an indication of the level of investment in testing. This information can also be used to estimate similar projects in the future.
- #33 Provides a measure of what was estimated at the beginning of the project vs. the actual effort taken. Useful to understand the variance (if any) and for estimating future similar projects.
- #34 Provides a variance between planned and actual scheduled followed. Useful to understand the variance (if any) and for estimating future similar projects.