introduction to defect prevention

8/13/2019 Introduction to Defect Prevention

1/32

Internal 2010 Infosys Technologies Limited, India

Infosys

Introduction to Defect PreventionSeptember, 2011

INFOSYS TECHNOLOGIES LIMITED

Mexico


2/32

Internal 2

COPYRIGHT NOTICE

2010 Infosys Technologies Limited, Bangalore, India. All rights reserved. Infosys believes theinformation in this document is accurate as of its publication date; such information is subject to changewithout notice. Infosys acknowledges the proprietary rights of other companies to the trademarks,product names and such other intellectual property rights mentioned in this document. Except asexpressly permitted, neither this document nor any part of it may be reproduced, stored in a retrievalsystem, or transmitted in any form or by any means, electronic, mechanical, printing, photocopying,recording or otherwise, without the prior permission of Infosys Technologies Limited and/or any namedintellectual property rights holders under this document.

Infosys Technologies LimitedHosur RoadElectronic City, 3rd CrossBangalore 560 100India.Telephone: (91) (80)28520 261-270Fax: (91) (80) 8520 362

Website: http://www.infosys.com

2010 Infosys Technologies Limited, India
http://www.infosys.com/http://www.infosys.com/


3/32

Internal 3

Date written (Sep/29/2011):


Tania FloresDeyanira AraujoErnesto CantuIsaias Varela

Authors


4/32

Internal 4 2010 Infosys Technologies Limited, India

Target Readers

Defect Prevention Anchors and Backups, Project Managers and DP team.

Keywords

Defect Prevention, Types of Defects, DP Plan, Peer Reviews, Verification and Validation, DP

Anchor and Team responsibilities.

Purpose of the Document

This document provides an Introduction about DP definitions, advantages, DP process, DP

Cycle and responsibilities for each role and involves related topics as V&V, Peer-Reviews

and the usage of IPM+ for defect tracking.

Target Readers, Keywords and Purpose


5/32


Defect Prevention

Defect-free software

does not exist.- Wietse Venema


6/32


Agenda

Defect Definition Types of Defects Common Fallacies in all Projects Cost of not identifying Defects DP Definition and Advantages Defect Prevention Purpose Validation and Verification

Verification Examples Validation Examples Defect Prevention Process

Defect Prevention Cycle Defect Prevention Plan Data needed for DP Defect tracking at IPM+ How to diagnose the process and reduce defects Most Common Problems Faced by DP Team DP Project Anchor Responsibilities DP Team Responsibilities References


7/32Internal 7 2010 Infosys Technologies Limited, India

Defect Definition

A defect can be termed as a flaw or discrepancy in anydeliverable which includes planning documents,estimations, requirement analysis, design documents,lines of code or test cases.

What is a Defect?


8/32Internal 8 2010 Infosys Technologies Limited, India

Types of Defects

The following are just some of the most common types of defects:Coding standards, modularity, hard coding, indentation, alignment, layout, comments, misspelling coding

Field length, quality of images, typos, security, mismatch of interfaces, user-friendly.

Functionality missed, test case missed, wrong test case, redundant/repeated test case, improperalgorithm.

Wrong interpretation of specs/requirements

Server response time, render response time, performance specifications requirements,

concurrency/throughput, timing.

Matching applications to environments, program libraries, minimum memory capacity; multitasking for

background calculations; interactive mode; a guaranteed floating point accuracy; etc

Application frameworks, component-bases development, program libraries.

Defects in product documentation requirements of corresponding design of artifacts, code, and test cases

and in traceability matrix

Defects in project plan document, lack of understanding of project management tools, wrongassumptions, errors in definition of cost, time, and high level resources (people, hardware and

software)

Physical organization, logical organization, protection, relocation, sharing, virtual memory, dynamicmemory allocation, garbage collector and paging.

When the requirement itself is ambiguous

When test cases in the test plan are not sufficient to test the code/modification.

Standards:

User Interface:

Design:

Logic:

Performance:

Portability:

Reusability:

Traceability:

Planning:

Memory Management:

Unclear Requirements:

Incomplete Test Case:


9/32


Common Fallacies in all Projects

All the defects that we get are cosmetic ones.

In our Project we don't have any defects.

In our process there are so many causes of defectsthat it is practically impossible to track them.


10/32


Cost of not identifying defects

Requirements Design Code Unit Test QA Test Release

1X10-20 X

80-100 X

Cost

World class benchmark: Defect removal

efficiency of 70-90% before QA Test

Early detection of defects reduces cost of fixing a defect


11/32


DP Definition and Advantages

1. Better Quality ofdeliverables andprogrammer productivity.

2. Reduce review and reworkeffort.

3. Better understanding ofissues by team members.

Can be defined as the systematic way of analyzing defects to determine theroot cause and taking required action to prevent it from occurring in thefuture.

DP Advantages

Defect Prevention

1. Reduce costs since defectscaught in early stages arecheaper to fix

2. Reduce schedule sincerework will be less.

Defect Detection (earlystage)


12/32


Defect Prevention Purpose

Reduce

Defects

Reduce

Rework

Less

EffortSpent

HighQuality

andProductivity


13/32


Verification and Validation

Ensures that the system complies with an organization standards andprocess. Did we build the right system?Verification

Physically ensures that the system operates according to plan byexecuting the system function through a series of test that can beobserved and evaluated.Didwe build the system right?

Validation

*Note: The verification and validation techniques can be applied to every element of the system.

Verification

Validation

Standards andprocess of design,

requirements,code, test etc.

To execute a reallife function

Find defectsbefore building

the system

DefectPreventio

n Process


14/32


Verification Examples

Verification Examples Explanation

Requirements

Reviews

The study of discussion of the system requirements to ensure

they meet stated user needs and are feasible.

Design ReviewsThe study of discussion of the system design to ensure it will

support the system requirements.

Code WalkthroughsAn informal analysis of the program source code to find

defects and verify coding techniques

Code InspectionsA formal analysis of the program source code to find defects as

defined by meeting system specifications.


15/32


Validation Examples

Validation Examples Explanation

Unit Testing The testing of a single program, module of unit of code.

Integrated Testing

The testing of related programs, modules of units of code.

Validates the multiple parts of the system interact according tothe system design.

System TestingThe testing of an entire system. It can include functional and

structural testing (White Box Testing ).

User Acceptance

Testing

It is a process to obtain confirmation that a system meets

mutually agreed-upon requirements. A Subject Matter Expert

(SME), preferably the owner or client of the object under test,

provides such confirmation after trial or review. In software

development, UAT is one of the final stages of a project and

often occurs before a client or customer accepts the new

system.


16/32


Defect Prevention Process

Identify

&

execute

checklist

Track

&

analyse

defects

Identify

solution

Execute

action

items

Validate

action

items

Identify

work

product


17/32



Identify

&

execute

checklist

Track

&

analyse

defects

Identify

solution

Execute

action

items

Validate

action

items

1. Identify Work Product

The DP anchor will identify theitems that will be reviewed for the

project. Reviews can either bePeer-Review or Self-Review. Anyclients deliverable should bereviewed.

Identify

work

product


18/32



Identify

&

execute

checklist

Track

&

analyse

defects

Identify

solution

Execute

action

items

Validate

action

items

Identify

work

product

2. Identify & execute checklist

A checklist should be identified andexecuted over every work product.The checklist will contain specificreview points that will help you toidentify defects in the deliverable.


19/32



Identify

&

execute

checklist

Track

&

analyse

defects

Identify

solution

Execute

action

items

Validate

action

items

Identify

work

product

3. Track & analyse defects

Any defect identified during thereview should be tracked.


20/32



Identify

&

execute

checklist

Track

&

analyse

defects

Identify

solution

Execute

action

items

Validate

action

items

Identify

work

product

4. Identify solution

The DP team will analyse thetracked defects during a Defect

Prevention Sessionor CARs.The output of this meeting is a

proposed solution with clear actionitems and deadlines for

completion.


21/32



Identify

&

execute

checklist

Track

&

analyse

defects

Identify

solution

Execute

action

items

Validate

action

items

Identify

work

product

5. Execute action items

The DP team makes sure the

identified action items areexecuted. Following up meetings

could be required for this.


22/32



Identify

&

execute

checklist

Track

&

analyse

defects

Identify

solution

Execute

action

items

Validate

action

items

Identify

work

product

6. Validate action items

The DP team validates theefficiency of the executed action

items by analyzing a portion ofnew defects and comparing thedefect injection rate betweenprevious and actual.


23/32


Defect Prevention Cycle

The Defect Prevention is a continuous process. Its a cycle that should be

performed during all the SDLC, since the project begins until it ends.

1.- Identify work product

2. Execute

checklist

3.- Track &analyse defects

4.- Identify solution

5.- Executeaction items

6.- Validate

action items

ContinuousDefect Prevention


24/32


Defect Prevention Plan

The Defect Prevention Plan is a long-term plan for defect

prevention activities within the project. It containsinformation like:

Objective & Scope

Strategy

DP Team

DP Tools

Checklist

Planned Schedule

Planned Effort


25/32


Data needed for DP

Criticality of Defect (Severity, Priority)

Defect Detected stage

Cause

Type

Defect Injected Stage

Configuration, Consistency,Design issues, Documentation,,

Incorrect Solution, Logic,Portability, Redundancy, etc.

Severity: Critical, Major, Minor,Cosmetic

Priority: High, Medium, Low

Requirement Analysis, HLD,Detailed Design, Build, Project

Initiation

Ambiguous Specification,Carelessness, Error in ExistingProgram, Impact Not Analyzed,

Improper Setup, InsufficientTime, Lack of Coordination, Lack

of Training, etc


26/32


Defect Tracking at IPM+

IPM+ allows projects to add reviews to a product, or set of work products, andit is presented to project members or other stakeholders for comment or

approval.You can add a review under Tracking > Reviews section.


27/32


How to diagnose the process and reduce defects

Normally we follow our intuition andprevious experience to assess the situationbut in the first place what we should use is aStructured way of finding defects and its

root cause by analyzing the data we haveand then we can go with our previousexperience to add value to the analysis.


28/32


Most Common Problems Faced by DP Team

1. Not logged on time

2. Logged with improper causes

3. Usually caught with cause as "Over Sight" or"Carelessness". This needs to be avoided if possible.

4. Not closed in IPM+ on time (same goes for Reviews).

Defects are:


29/32


DP Project Anchor Responsibilities

Generate a DP Plan for the project.

Identify the work products (deliverables) that will be reviewed as part of V&V process.

Identify validation checklists for every deliverable and tailor it if needed.

Verify that Peer or Self Reviews are being executed.

Verify the checklist identified are executed and is updated if required.

Make sure that defects are being tracked at IPM+

Execute Defect Prevention Meetings (CAR sessions) as per defined in the DP Plan.

Identify solutions and create/monitor action plan until closure.

Provide any DP information at Infosys DP SharePoint sites.

Bring awareness of Defect Prevention to the rest of their team.

Investigate on DP tools to be implemented in the project.

Collect and distribute Lessons Learned and Best Practices for DP across the team .


30/32


DP Team Responsibilities

Execute peer-reviews and record defects.

Utilize effectively the checklists.

Make sure data tracked from reviews is accurate.

Verify the defects are being tracked in IPM+.

Participate actively in the CAR sessions.

Suggest actions in the DP session to prevent the occurrence ofdefects.

Execute the action items assigned until closure.

Attend any DP meeting/training required.

Suggest lessons learned and best practices.

DP team should be well organized and there should be properassignment ofresponsibilities to the DP team.


31/32

Internal 31

1.Infosys PRIDE2.Infosys KSHOP3.Defect and Problem Prevention Guidelines.doc at PRIDE4.Defect Prevention Plan template at PRIDE5.CSQA CBOK 20066.chrk09.blogspot.com

7.http://www.famousquotes.com/category/defect /8.http://en.wikipedia.org/wiki/Wietse_Venema9.http://www.defectmanagement.com/defectmanagement/dprevention.htm10.http://www.icspi.com/tutorials-h2007.htm


References


32/32

Inte n l 2010 I f T h l i Li it d I di

introduction to defect prevention

Documents