Software Quality Assurance Lecture #4 By: Faraz Ahmed.

Post on 11-Jan-2016

221 views 1 download

Tags:

Transcript of Software Quality Assurance Lecture #4 By: Faraz Ahmed.

Software Quality Assurance

Lecture #4By: Faraz Ahmed

Contents

Projects

1. Ecommerce Website2. Inventory Management System3. Point of Sale system4. Employee Management System5. Patient Management System

Pareto Principle

080% of the problems stem from 20% of causes

0This applies to many aspects of life such as sales.

Richest 20% Income 82.70%

Walkthroughs

0 Informal meetings

0Peer reviews

0Code Reviews

0Advantages0 Exchanging ideas0 Getting team on board

Software Inspections

0After the popular Fagan Inspection0 Planning:0 Overview: Focus and role definition0 Preparation: Reviewing of roles0 Inspection Meeting: Finding of defect0 Rework0 Follow-up: moderator verifies.

Roles in inspections

0Moderator

0Author/Designer/Coder

0Tester (many people possible)

Defect

0An error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving in the intended way.

Defect Management Process

0A multi-step approach to defect management.

0Defects cannot be removed altogether

0But we can suppress their negative effect to some extent.

Defect Management Process (contd.)

0 Defect Prevention

0 Deliverable baseline

0 Defect Discovery

0 Defect Resolution

0 Process Improvement

0 Management Reporting

Defect Prevention

0 Identify ‘critical’ risks

0Estimate expected impact

0Minimize expected impact

Identify Risks

0Risks that could effect the successful completion of project.

0E.g. 0 Missing a key requirement0 A key component not working as expected0 Technology not available (e.g. as in avatar)

0Only those risks that are specific to project

Estimate Expected Impact

0Two important aspects: Probability and Cost

0E(stimate) = P(robability) x I(mpact)

0The impact is only low when there are reasons justifying it.

Minimize Impact

0 The impact becomes severe if it is left for long.

0 Eliminate the Risk

0 Reduce the Probability of a Risk Becoming a Problem:  Most strategies will fall into this category.  Inspections and testing are examples of approaches that reduce, but do not eliminate, the probability of problems.

0 Reduce the Impact if there is a Problem:  In some situations, the risk can not be eliminated, and even when the probability of a problem is low, the expected impact is high.  

Deliverable Baselined

0Baselined after reaching a milestone/increment

0Changes are more expensive.

0Activities0 Identify key deliverables 0Define standards for each deliverable

Defect Discovery

0A defect is only realized once the software engineers acknowledge a problem

0This mechanism of reporting should be available reducing the time.

0Activities0 Find Defect0 Report Defect0 Acknowledge Defect

Find Defect

0Ways0During development ( SQA, inspections, testing etc)

0Three categories 0 Static Techniques: Testing without running software. E.g.

Code review. 0 Dynamic Techniques: Physical execution. E.g. test cases,

unit tests. 0 Operational Techniques: found in a deliverable

Fact Finding!

0When Shell Oil followed the inspection process, they recorded the following results:

0 For each hour spent in the inspection process, ten hours were saved!

0 Their defect removal efficiency with inspections was 95-97% versus roughly 60% for systems that did not use inspections.

Report Defect

0Easier to report within team

0What happens when you are a user? 0Developers do not accept mistake0Users not sure whether it is really a problem or CHANGE

0A process is needed to facilitate this understanding.

Acknowledge Defects

0One hurdle is to replicate the user environment.

0Trap events as they occur!

0May lead to friction and might need arbitration!

Defect Resolution Process

0After a valid defect has been acknowledged

0Prioritize Risk: ‘Age’, priority and actions to be taken while fixing.

0Schedule Fix and Fix defect: In additions, artifacts might be updated.

0Report resolution

Report Resolution

0The nature of the fix

0When the fix would be released

0How the fix would be released.

Process Improvement

0The retrospective aspect of the whole process.

0 If this defect has gotten so far undetected, can their be others?

0How to minimize a similar defect way before?

Communicating

0Defect rates, defect trends, types of defects, failure costs.

0Changes in timeline

0Negotiations with client?

0For forecasting new projects.

QUIZ!!

0What are non-goals?

0 In “Joel on Software”, what were the recommendations for writing a functional spec? Mention atleast one.

Thank you for showing up early!