МАРИНА ШУЛЬГА «Чому розробка ядерних програм США може навчити софтверних тестерів. Risk Assessment в дії» Lviv QA Day 2018
•Download as PPTX, PDF•
0 likes•714 views
Lviv Quality Assurance Day 2018 МАРИНА ШУЛЬГА «Чому розробка ядерних програм США може навчити софтверних тестерів. Risk Assessment в дії» Телеграм канал: wwww.t.me/goqameetup Фейсбук сторінці: www.fb.com/goqaevent Сайт: www.qaday.org
Recommended
Recommended
More Related Content
What's hot
What's hot (17)
Similar to МАРИНА ШУЛЬГА «Чому розробка ядерних програм США може навчити софтверних тестерів. Risk Assessment в дії» Lviv QA Day 2018
Similar to МАРИНА ШУЛЬГА «Чому розробка ядерних програм США може навчити софтверних тестерів. Risk Assessment в дії» Lviv QA Day 2018 (20)
More from GoQA
More from GoQA (20)
Recently uploaded
Recently uploaded (20)
МАРИНА ШУЛЬГА «Чому розробка ядерних програм США може навчити софтверних тестерів. Risk Assessment в дії» Lviv QA Day 2018
- 2. QA Manager / Error Manager 6 years of IT experience Presenting since 5th grade Scientific researches Customer pre-sale IT Academy course QA basic course Certification course Team trainings Knowledge sharing presentations Healthcare, retail, infrastructure, virtualization, automotive
- 4. A factor that could result in future negative consequences usually expressed as impact and likelihood. or A problem that has not been materialized yet and possibly will never be.
- 9. • Scope • Time • Cost • Quality • Risk • Communication • Human Resources • Procurement • Integration
- 10. Project risk - success of the project: Time Budget Functionality Quality Product risk - suitability for purpose of the product: Does the product has the potential to harm people or property? Does it do what it is supposed to do? Does it do what it is not supposed to do? Business risk - market timing and feature mix: Is this a good time to introduce this software to the market? Do I have the right set of features for this market?
- 16. Risk identification: figuring out different project and quality risks for the project. Risk analysis: assessing the level of risk typically based on likelihood and impact for each identified risk item. Risk mitigation (risk control): consists of mitigation, contingency, transference, and acceptance actions for various risks.
- 17. Classify the risks as Project, Product or Business Confirm that they are risks, not issues or problems
- 18. • Information gathering • Risks identification • Risk diagramming
- 19. • Risk workshops and brainstorming • Nominal group • Delphi technique • Interviews • Project retrospectives
- 20. • System or process flow charts • Influence Diagrams • Cause and effect diagram (Ishikawa)
- 21. • Checklist analysis (CLA) • Assumptions analysis • Documentation reviews • Expert judgement / Independent assessments • Calling on past experience / Lessons Learned
- 22. • Pareto Diagram • SWOT analysis • Fault Tree Analysis (FTA) • Failure mode and effects analysis (FMEA)
- 23. Operating context and environment Identification the internal and external risks Various contributing and leading factors Characterize and prioritize the list of risks Assessment Capture risks Review risks and identify the range of options
- 25. Risk probability is the likelihood of the risk occurring Risk impact assumes that the risk has turned into a problem and is a statement of how big the problem is Level of risk = probability of the risk occurring ×impact if it did happen
- 29. Potential failure mode Potential cause(s) / mechanism Mission Phase Local effects of failure Next higher level effect System Level End Effect (P) Probability (estimate) (S) Severity (D) Detection Detection Dormancy Period Risk Level P*S (+D) Actions for further Investigation / evidence Mitigation / Requirements
Editor's Notes
- Unplanned work white board
- As we move from risks to issues, and then to problems, the number of choices to avoid the unwanted consequence decreases. Let’s try to find all choices if a risk is potential issues with a third-party application starting from risk identification on an early stage. Think about ways to avoid compatibility problems. [pause] Now, imagine that you are in the middle of the project. In a few weeks, you need to start using a third-party application, but compatibility risk has been ignored or skipped. Here you faced an issue. Think about ways to avoid compatibility problems on this stage. As you can notice, issue leaves us just few options to stop the problem. [pause] Imagine that there is a real problem, and it is too late to prevent it. Obviously, it is better to do risk management timely not to conquer the real problems.
- Omit some key function that the customers specified, the users required or the stakeholders were promised. Unreliable and frequently fail to behave normally. Cause financial or other damage to a user or the company that user works for. Quality characteristic issues, which might not be functionality, but rather security, reliability, usability, maintainability or performance.