11.final inspection v1.3

8/4/2019 11.Final Inspection v1.3

1/22

Copyright 2006 FPT Software 1FPT SOFTWARE TRAINING MATERIAL Internal use 04e-BM/NS/HDCV/FSOFT v2/2

Final inspection

Instructor: Hoang Anh Duc

HN Branch QA

Version: 1.3

Date: Jun-08


2/22


Purpose: To improvefinal inspection (FI) capability

Attendees : Inspectors

have software testing experience in 2 projects at least

have basic knowledge of CM activity

Course duration:

1 hours for theory

2 hours for practice to create FI checklist with a case-study

Introduction


3/22


FI with 4 Ws

FI Flow

How to plan for FI

How to use FI checklist

How to create Specific items

How to report FI result

Contents


4/22


FI with 4 Ws

What for?

To guarantee the quality and integrity of the components to be released

This activity is applied for all releases to customer especially mandatoryfor the ones planned in WO

When to do?

Before delivering the products to customer.

Who to do?

QA by default

Or assigned person in special case

Where to do? Desk-check with project team

Build the package to deep-check at Inspectors own computer


5/22


FI Flow

Do FI

Evaluate actual results

FINISH

Log defects into DMS

Satisfied?

Results Satisfied?

Check FI

Pre-conditions

Plan for FI

Customize FI checklist (Develop

acceptance criteria & specific items)

START

N

N

Y

Y


6/22


How to plan for FI

Make FI schedule: Get the deliverable schedule from PM

Make FI schedule including tasks

Creating specific items in FI checklist Doing FI Reporting FI

Make acceptance criteria clear for each delivery Tool: customized final inspection checklist


7/22 Copyright 2006 FPT Software 7FPT SOFTWARE TRAINING MATERIAL Internal use 04e-BM/NS/HDCV/FSOFT v2/2

How to plan for FI

Make FI effort estimation

In CTI-0100 project Project information:

Developing web-based room booking system; estimated effort 650pds; ~8Developers; 2.5 Testers; 1 QA

For interim release (Scope: send to customer for code review):

4 phs: to create specific items and to check coding convention

For UAT release

4 pds: to study Req 2 pds: to create specific items covering 40% of function Req 3 pds: to do FI covering 40% of function Req at first round

FI effort accounts ~ 4.5% of total project effort

In JIP project

Project Information: Scope study Spec Code PGs Create & execute UT CreateUT evidence. Team has no Testers. ~ Daily release

~3 phs to check 1 PG (500 LOC) at first round

FI effort accounts ~ 8% of total project effort



How to plan for FI

Suggested metrics

(source from ~35 projects submitted in FI program for measurement)

Metrics Unit Value Formula Note

FI Cost % 7 Total actual effort to create & do FI /Total actual project effort

D-C-UT

5 D-C-UT-IT-ST

6 General

FI Leakage (%) % 40 Number of defects by found customer/Total number of defects found (by

customer + by FI)FI Effectiveness Wdef/pd 7 Total wdef by FI/ Total effort spent on

FITest effect ofFSoft = 3-5-7

Project Leakage Wdef/UCP 0.15 Total wdef of post releases (after UATrelease)/ actual product size



How to plan for FI

Tips when planning

If dedicated for FI activity, one QA should only take care of2 projects havingthe same size, ensuring the 2 delivery schedules are not concurrent

If dedicated for QAs full activities, one QA should only take care of 1 project with full activities and 2 projects with process tasks

Or 1 project with full activities and 1 smaller project with FI task, ensuring the 2delivery schedules are not concurrent

Project size here should include ~3-8 Developers, ~1-3 Testers




Purpose ofGeneral items

To check whether a product is actually ready for FI To check whether all requests about FSofts final inspection procedure are

satisfied

Steps to follow Refer to Final Inspection Checklist template




Tips when checking General items

Pre-condition items: Row 10: Khi nhn c request lm FI, facing confirm 1 ln na v Acceptance

Criteria

Row 13: Trng hp release c Test Report m lc request lm FI vn cha cTest Report phi nghi ng ngay

Row 14: Trong khong >1 week trc ngy lm FI, phi chm sc chu o DMSv ni tnh d n lin quan n release

CM items:

/v open defects/ issues trong Release Notes, QA phi c li, nm na cng phihiu n ni v ci g. Nu technique qu, th check cho ngi khc trong team.(Lun suy ngh Mnh cn khng hiu th lm sao khch hng hoc bn th 3hiu)

T mnh deploy code l tt nht. Nu khng phi chng kin tn mt, team getcode t Release folder deploy, v gi mail cha test link /v release bug-fix, check hoc hi PM file code no c update ln ny, sample-

compare Modified date vi source code ca Release trc




Purpose ofSpecific items To check whether specific requirements are satisfied for products in each release

Steps to follow After passing pre-conditions, QA use Specific items together General items to start

checking




Tips when testing Specific items

Spend ~1 hour overview li DMS, t rt ra function no Tester bt k, t QA cn nhc set priority thp lc test hoc ko check k na

Qun trit tinh thn, tm ra defect th log DMS, s clarify sau trnh mt thi gian

Trng hp tranh chp, team vn mun release, nn keep defect ny vo DMS sau ny d trace li.

Khng thi gian/ Urgent case, c th test theo case ca QA nhng invite Testerngi cng




Step 1: Define the information needed to gather/ catch-up

Compare the project scope among Proposal, Estimation and SRS so that youcan ensure the Acceptance criteria/ Customers expectation are fullyimplemented

Pay attention at non-functional reqs such as Performance, test scope.

Step 2

Study Req under Screen/ Buz/ Process flow view to get the overview of systembusiness

If the workflow is not mentioned in Req, self-write down the main workflowwith Actors/ Status




Step 3

Write down check-items with the objective to focus on main workflow

List functions in the work flow List sub-functions (if any) mapping with the main functions Add detailed check-items for valid cases Add detailed check-items for normal invalid cases Add detailed check-items for others if needed (Optional)




Step 4Write down check-items with additional objectives upon a specific project. Ex:

System security

It is best to draw a security matrix Or add actors and their rights in each cases in Step 4

Coding Convention

It is best to convert from Coding convention word file to a checklist-excel fileNumeric format/ boundary

It is best to define real test data when financial domain

Step 5

Catch-up the up-to-date information one day before FI date Update common defects/ issues into the checklist Study latest Q&A file with customer Ask Testers/Devs (if any) about their concerns so that you can note



Case-study



How to track

Defects found by FI are logged into DMS with QC Activity = Final Inspection

Effort to create FI checklist

Process = Quality Control

Work = Create Work product = Project record

Effort to do FI

Process = Quality Control Work = Review Work product = Release notes


19/22


Reminder

Believe in your understanding of Req. Dont wait for teams review orsupport too much

It is best to self-deploy the package. If impossible, witness team to deploythe package and ask him to send the deployment link

For the release of documents only, if the content update is not more than20% (based on updated pages/ total), FI can be skipped

For unplanned releases, PM must contact QA at least one day before FItime to get the commitment


20/22


How to report

Final inspection is Passed if The items with mandatory priority are marked 'OK'

Send the filled-up checklist to inform project team of the result

Final inspection is Not Passed if At least one of the items with mandatory priority

is marked 'NOK'

Send the filled-up checklist to inform related people (QA Leader, PM, etc)of the result.

PM still wants to deliver, QA should check the evidence that customer orQA Leader agrees for this case


21/22


References

Final inspection checklist

Release note template

QA guideline


22/22

Copyright 2006 FPT Software 22 C

Questions and Answers

11.final inspection v1.3

Documents