Risk Analysis for Testing Based on Chapter 9 of Text Based on the article “ A Test Manager’s Guide to Risks Analysis and Management” by Rex Black published.

Slides:



Advertisements
Similar presentations
Testing and Quality Assurance
Advertisements

Software Testing 3 Damian Gordon.
Chapter 17 I.Omaima Al-Matrafi
Where does Failure Mode and Effects Analysis (FMEA) come from?  Developed by the Aerospace industry in the1960s  Spread to the Automotive industry 
Failure Mode and Effect Analysis
Chapter 7 - Software Development1 Chapter 7 Software Development A Textbook aimed at protecting consumers Software Quality Links Ian Foster and Grid Computing.
FMEA Failure Mode and Effects Analysis
Reliability Risk Assessment
Overview Lesson 10,11 - Software Quality Assurance
SQM - 1DCS - ANULECTURE Software Quality Management Software Quality Management Processes V & V of Critical Software & Systems Ian Hirst.
CS 325: Software Engineering March 26, 2015 Software Quality Assurance Software Metrics Defect Injection Software Quality Lifecycle Measuring Progress.
Non-functional requirements
Software Dependability CIS 376 Bruce R. Maxim UM-Dearborn.
Failure Mode and Effects Analysis FMEA
Software Project Management
Software Testing Verification and validation planning Software inspections Software Inspection vs. Testing Automated static analysis Cleanroom software.
Software Quality SEII-Lecture 15
Software Project Management Fifth Edition
Quality in Product and Process Design Pertemuan 13-14
EE551 Real-Time Operating Systems
COURSE TITLE: 1 Software Quality Assurance. Course Aims Introduction to software quality assurance. Software testing terminology. Role and responsibility.
 The software systems must do what they are supposed to do. “do the right things”  They must perform these specific tasks correctly or satisfactorily.
Sept - Dec w1d11 Beyond Accuracy: What Data Quality Means to Data Consumers CMPT 455/826 - Week 1, Day 1 (based on R.Y. Wang & D.M. Strong)
WHAT IS SYSTEM SAFETY? The field of safety analysis in which systems are evaluated using a number of different techniques to improve safety. There are.
Analyze Opportunity Part 1
Software Software is omnipresent in the lives of billions of human beings. Software is an important component of the emerging knowledge based service.
Copyright © Jerzy R. Nawrocki ISO 9126 and Non-functional Requirements Requirements.
FAULT TREE ANALYSIS (FTA). QUANTITATIVE RISK ANALYSIS Some of the commonly used quantitative risk assessment methods are; 1.Fault tree analysis (FTA)
Slide 1V&V 10/2002 Software Quality Assurance Dr. Linda H. Rosenberg Assistant Director For Information Sciences Goddard Space Flight Center, NASA
Lecture: Reliability & FMECA Lecturer: Dr. Dave Olwell Dr. Cliff Whitcomb, CSEP System Suitability.
University of Palestine software engineering department Testing of Software Systems Testing throughout the software life cycle instructor: Tasneem.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Software Verification, Validation and Testing.
Lecture 7 Risk Analysis CSCI – 3350 Software Engineering II Fall 2014 Bill Pine.
Software Methods Mö/ slide 1 Methods and Techniques of Software Quality Management ICEL Quality Management Systems: Methods and Techniques of Software.
About Quality Pre paired By: Muhammad Azhar. Scope What is Quality Quality Attributes Conclusion on software Quality Quality Concepts Quality Costs.
CS551 - Lecture 5 1 CS551 Lecture 5: Quality Attributes Yugi Lee FH #555 (816)
Software Testing for Intelligent Robots Justin Peckner Maria Velasquez November 13, 2012.
ME 4054W: Design Projects RISK MANAGEMENT. 2 Lecture Topics What is risk? Types of risk Risk assessment and management techniques.
Chapter 2 Object-Oriented Paradigm Overview. Getting Acquainted with the Class Project Read the requirements specification carefully Make note of any.
SEN 460 Software Quality Assurance
Software Testing and Quality Assurance 1. What is the objectives of Software Testing?
Attributes Availability Reliability Safety Confidentiality Integrity Maintainability Dependability Means Fault Prevention Fault Tolerance Fault Removal.
Failure Modes and Effects Analysis (FMEA)
Failure Modes, Effects and Criticality Analysis
Lean Six Sigma: Process Improvement Tools and Techniques Donna C. Summers © 2011 Pearson Higher Education, Upper Saddle River, NJ All Rights Reserved.
ON “SOFTWARE ENGINEERING” SUBJECT TOPIC “RISK ANALYSIS AND MANAGEMENT” MASTER OF COMPUTER APPLICATION (5th Semester) Presented by: ANOOP GANGWAR SRMSCET,
Ethics in Information Technology Chapter 7 Software Development Ethics in Information Technology.
ISQB Software Testing Section Meeting 10 Dec 2012.
Chapter 2 Object-Oriented Paradigm Overview
TOTAL QUALITY MANAGEMENT
CSCE 548 Secure Software Development Risk-Based Security Testing
Software Development and Safety Critical Decisions
Critical systems design
SEVERITY & PRIORITY RELATIONSHIP
Quality Exercise 2 Instructions
FMEA.
Failure Modes and Effects Analysis (FMEA)
Quality Exercise 2 Instructions
Quality Exercise 2 Instructions
Risk Assessment: A Practical Guide to Assessing Operational Risk
GE 6757 TOTAL QUALITY MANAGEMENT
Charakteristiky kvality
and Jose-Norberto Mazón University of Alicante
Software Quality Assurance Lecture 3
Failure Mode and Effect Analysis
Failure Mode and Effect Analysis
© Oxford University Press All rights reserved.
ISO/IEC Systems and software Quality Requirements and Evaluation
Tomaž Špeh SURS TF SERV, Luxembourg,
Presentation transcript:

Risk Analysis for Testing Based on Chapter 9 of Text Based on the article “ A Test Manager’s Guide to Risks Analysis and Management” by Rex Black published in Software Quality Professional, Vol. 7, No1, pp Will follow the flow of the article more than chapter 9.

The question is What are you testing? –What are areas of the system do you think is high risk? How do you know which ones are the most important one? –How do you know which ones are high risk? What is a risk ? --- –it is A Potential Undesirable Outcome So for system’s quality, a potential undesirable outcome is when the system fails to meet its expected behavior. The higher this potential of undesirable outcome is, the more we want it not to occur. 1.We test to find these high potentially undesirable outcomes and get them fixed before release 2.We test to show that the areas tested do not harbor these high potentially undesirable outcomes.

Quality Risks For most systems, it is not probable to test all possibilities; so we know there are errors shipped. (There are risks!) Two major concerns about risks are –How likely is it that certain risks (the potential problems) exist in the system? –What is the impact of the risk to: Customer/user environment Support personnel workload Future sales of the product

Quality Risk Analysis In quality risk analysis for testing we perform 3 steps: –Identify the risks (in the system) –Analyze the risks –Prioritize the risks

5 Different Techniques for Quality Risk Analysis All 5 techniques involve the three steps of identifying, analyzing and prioritizing based on a variety of sources for data and inputs. –Informal Analysis –ISO 9126 Based Analysis –Cost of Exposure Analysis –Failure Mode and Effect Analysis –Hazard Analysis One may also use combinations of these

Informal Quality Analysis Identified by a “cross-section” of people –Requirements analyst –Designers –Coders –Testers –Integration and Builders –Support personnel –Possibly users/customers Risks are identification, analysis and prioritization based on: –Past experiences –Available data from inspections/reviews of requirements and design –Data from early testing results Mission-critical and safety-critical system tests would need to “formalize” the analysis of the past inspection/review results and tests results

ISO 9126 Quality Risk Analysis ISO 9126 defines on 6 Characteristics of Quality. –Functionality: suitability, accurateness, interoperability, compliance, security –Reliability: maturity, fault tolerance, recoverability –Usability: understandability, learnability, operability –Efficiency: time behavior, resource behavior –Maintainability: analyzability, changeability, stability, testability –Portability: adaptability, installability, conformance, replaceability These 6 characteristics form a convenient list of prompters for the identification, analysis, and prioritization of risks (potential problems) Good to follow an industry standard, especially for large software systems which require a broad coverage of testing. ISO 9126 Functionality Reliability Usability Portability Maintainability Efficiency

Cost of Exposure Analysis Based on two factors: –The probability of the risk turning into reality or the probability that there is a problem –The cost of loss if there is a problem The cost of loss may be the viewed as cost of impact to users in (work hours delayed, material loss, etc.) The cost of loss may also be viewed from a reverse perspective --- cost of fixing what the problem caused. –Based on the probability of occurrence and the cost of impact, one can prioritize the test cases. Consider three risks –Risk 1: prob. of occurrence (.3) x cost ($20k) = $6k –Risk 2: prob. of occurrence (.25) x cost ($10k) = $2.5k –Risk 3: prob. of occurrence (.1) x cost ($100k) = $10k –In this case, you will prioritize in the order: »Risk 3, »Risk 1, and »Risk 2 Both factors are hard to estimate for normal testers; need experiences.

Failure Mode/Effect Analysis (FMEA) This methodology was originally developed by the US military (MIL-P-1629) for detecting and determining the effect of system and equipment failures, where failures were classified according to their impact to: – a) the mission success and – b) personnel/equipment safety. The steps are ( for each mechanical-electrical component ): –Identify potential design and process failures –Find the effect of the failures –Find root cause of failures –Prioritize the recommended action based on risk priority number which is computed by (probability of risk occurrence x severity of the failure x probability of detection of the problem) --- –Recommend actions For software ( for each function): –Same steps apply, but the reasons for failure are quite different from the physical component. There is no aging and wear/tear Mechanical stress needs to be replaced by performance stress similar to Cost of Exposure Analysis

Hazard Analysis This is similar to Failure Mode and Effect Analysis except we look at the effects first and work backward and trace at potential cause(s). In order to list the effects (or anticipate problems), the testers will need to be fairly experienced in the application discipline and software technology

Ranking of Problems (Hutcheson example) Rank = 1 (Highest priority) –Failure would be critical –Required item by service level agreement (SLA) Rank = 2 (High Priority) –Failure would be unacceptable –Failure would border the SLS limit Rank = 3 (Medium priority) –Failure would be survivable –Failure would not endanger the SLA Rank = 4 (Low priority) –Failure would be trivial and has small impact –Failure would not be applicable to SLA

Risk Ranking Criteria (Hutcheson Example & Yours) (Hutcheson) Similar in concept to the ISO 9126’s 6 characteristics –Is this risk a required item: (1= must have = nice to have) –What is the severity of risk: ( 1 = most serious = least serious) –What’s the probability of occurrence: (1= most likely = least likely) –Cost of fixing problem if it occurs: (1 = most expensive = least exp.) –What is the failure visibility: (1 = most visible least visible) –How tolerable will users be: (1 = most tolerable least tolerable) –How likely will people succeed: (1= fail = succeed) Which from the above would you keep and what new ones would you add? e.g.: - How difficult is it to test for or discover this problem (1 hard =easy)