Software Quality Assurance- Introduction

Software Quality Assurance

1. MODULE1: SOFTWAREQUALITY
ASSURANCE

2. THESOFTWAREDEVELOPMENT LIFE
CYCLE(SDLC)
It isa structured process that enables the production
of high-quality, low-cost software, in the shortest
possible production time.
The goal of the SDLC is to produce superior software
that meets
2

3. 3
SOFTWAREDEVELOPMENT LIFECYCLE

4. DEFECT/BUGLIFECYCLEINSOFTWARETESTING
It is the specific set of states that defect or bug goes
through in its entire life.
The purpose is to easily coordinate and communicate
current status of defect which changes to various
assignees and make the defect fixing process
systematic and efficient.
Defect Statusor Bug Status is the present state from
which the defect or a bug is currently undergoing.
The goal is to precisely convey the current state or
progress of a defect or bug in order to better track and
understand the actual progress of the defect life cycle.
4

5. 5

6. DEFECTSTATESWORKFLOW
The number of states that a defect goes through varies from project
to project
New:When a new defect is logged and posted for the first time. It
is assigned a status as NEW.
Assigned:Once the bug is posted by the tester, the lead of the
tester approves the bug and assigns the bug to the developer team
Open: The developer starts analyzing and works on the defect fix
Fixed: When a developer makes a necessary code change and
verifies the change, he or she can make bug status as “Fixed.”
Pending retest: Once the defect is fixed the developer gives a
particular code for retesting the code to the tester. Since the
software testing remains pending from the testers end, the status
assigned is “pending retest.”
Retest: Tester does the retesting of the code at this stage to check
whether the defect is fixed by the developer or not and changes the
status to “Re-test.”
6

7. WHATISQUALITY?
Quality–developed product meets it’s specification
Problems:
•Developmentorganizationhasrequirementsexceedingcustomer's
specifications(addedcostofproductdevelopment)
•Certainqualitycharacteristicscannotbespecifiedinunambiguousterms(i.e.
maintainability)
•Eveniftheproductconformstoit’sspecifications,usersmaynotconsiderit
tobeaqualityproduct(becauseusersmaynotbeinvolvedinthedevelopment
oftherequirements)

8. 8
WHATISQUALITYMANAGEMENT ?
Quality Management–ensuring that required level of product quality is achieved
• Defining procedures and standards
• Applying procedures and standards to the product and process
• Checking that procedures are followed
• Collecting and analyzing various quality data
Problems:
• Intangible aspects of software quality can’t be standardized (i.eelegance
and readability)

9. WHYQUALITYISIMPORTANT?
Why business should be concerned with quality:
Quality is competitive issue now
Quality is a must for survival
Quality gives you the global reach
Quality is cost effective
Quality helps retain customers and increase profits
Quality is the hallmarks of world-class business

10. 10
WHATARESQA, SQP, SQC, ANDSQM?
SQA includes all 4 elements…
•Software Quality Assurance–establishment of network of
organizational procedures and standards leading to high-
quality software
2.Software Quality Planning–selection of appropriate
procedures and standards from this framework and adaptation
of these to specific software project
3.Software Quality Control–definition and enactment of
processes that ensure that project quality procedures and
standards are being followed by the software development
team
4.Software Quality Metrics–collecting and analyzing quality
data to predict and control quality of the software product
being developed

11. ELEMENTS OFSQA
1.SoftwareQualityAssurance–establishmentofnetworkof
organizationalproceduresandstandardsleadingtohigh-
qualitysoftware
2.SoftwareQualityPlanning–selectionofappropriateprocedures
andstandardsfromthisframeworkandadaptationoftheseto
specificsoftwareproject
3.SoftwareQualityControl–definitionandenactmentof
processesthatensurethatprojectqualityproceduresandstandards
arebeingfollowedbythesoftwaredevelopmentteam
4.SoftwareQualityMetrics–collectingandanalyzingqualitydata
topredictandcontrolqualityofthesoftwareproductbeing
developed

12. GOALSOFSQA
1. to improve software quality by monitoring both the process
and the product
2. to ensure compliance with all local standards for SE
3. to ensure that any product defect, process variance, or
standards non-compliance is noted and fixed

13. SOFTWAREQUALITYASSURANCE(SQA)
Itisawaytoassurequalityinthesoftware.
Itisthesetofactivitieswhichensureprocesses,proceduresas
wellasstandardsaresuitablefortheprojectandimplemented
correctly.
Itisaprocesswhichworksparalleltodevelopmentofsoftware.
Itfocusesonimprovingtheprocessofdevelopmentofsoftware
sothatproblemscanbepreventedbeforetheybecomeamajor
issue.
ItisakindofUmbrellaactivitythatisappliedthroughoutthe
softwareprocess.
SoftwareQualityAssurancehas:
1.Aqualitymanagementapproach
2.Formaltechnicalreviews
3.Multitestingstrategy
4.Effectivesoftwareengineeringtechnology
5.Measurementandreportingmechanism

14. MAJORSOFTWAREQUALITYASSURANCEACTIVITIES:
1. SQA Management Plan:
Make a plan for how you will carry out the SQA through out the project.
Think about which set of software engineering activities are the best for project. check
level of SQAteam skills.
2. Set The Check Points:
SQA team should set checkpoints.
Evaluate the performance of the project on the basis of collected data on different check
points.
3. Multi testing Strategy:
Do not depend on a single testing approach.
When you have a lot of testing approaches available use them.
4. Measure Change Impact:
The changes for making the correction of an error sometimes re introduces more errors
keep the measure of impact of change on project.
Reset the new change to change check the compatibility of this fix with whole project.
5. Manage Good Relations:
In the working environment managing good relations with other teams involved in the
project development is mandatory.
Bad relation of SQAteam with programmers team will impact directly and badly on
project. Don’t play politics.

15. QUALITYIMPROVEMENT –THEWHEELOF6 SIGMA
Six Sigma

16. QUALITYIMPROVEMENT –SIXSIGMAPROCESS
• Visualize–Understand how it works now and imagine how it will work in the future
• Commit–Obtain commitment to change from the stakeholders
• Prioritize–Define priorities for incremental improvements
• Characterize–Define existing process and define the time progression for
incremental improvements
• Improve–Design and implement identified improvements
• Achieve–Realize the results of the change

17. BENEFITSOFSOFTWAREQUALITYASSURANCE
1.SQA produces high quality software.
2.High quality application saves time and cost.
3.SQA is beneficial for better reliability.
4.SQA is beneficial in the condition of no maintenance
for a long time.
5.High quality commercial software increase market
share of company.
6.Improving the process of creating software.
7.Improves the quality of the software.

18. MEASURES OFSOFTWAREQUALITYASSURANCE
1.Reliability –
It includes aspects such as availability, accuracy, and recoverability of system to
continue functioning under specific use over a given period of time. For example,
recoverability of system from shut-down failure is a reliability measure.
2.Performance –
It means to measure throughput of system using system response time, recovery time,
and start up time. It is a type of testing done to measure performance of system under
a heavy workload in terms of responsiveness and stability.
3.Functionality –
It represents that system is satisfying main functional requirements. It simply refers
to required and specified capabilities of a system.
4.Supportability –
There are a number of other requirements or attributes that software system must
satisfy. These include-testability, adaptability, maintainability, scalability, and so on.
These requirements generally enhance capability to support software.
5.Usability –
It is capability or degree to which a software system is easy to understand and used
by its specified users or customers to achieve specified goals with effectiveness,
efficiency, and satisfaction. It includes aesthetics, consistency, documentation, and
responsiveness.

19. SOFTWAREQUALITYPLAN
Tailoring-SQPshouldselectthoseorganizational
standardsthatareappropriatetoaparticularproduct
Standardization-SQPshoulduse(callout)onlyapproved
organizationalprocessandproductstandards
Ifnewstandardsarerequiredaqualityimprovementshould
beinitiated
Elements-SQPelementsareusuallybasedontheISO-
9001modelelements
SQPisnotwrittenforsoftwaredevelopers.It’swrittenfor
SQE’sasaguideforSQCandforthecustomertomonitor
developmentactivities
Thingslikesoftwareproduction,softwareproductplansand
riskmanagementshouldbedefinedinSDP,IP
QualityFactor’sshouldn’tbesacrificedtoachieveefficiency.
Don’ttakethejobifqualityprocesscan’tbeupheld

20. SOFTWARE QUALITYCONTROL
Qualitycontrolisdefinedas
“asetofactivitiesdesignedtoevaluatethequality
ofadevelopedormanufacturedproduct”
qualitycontrolinspectionandotheractivitiestakeplace
beforetheproductisshippedtotheclient
prevents causes of errors, and detect and correct them
early in the development process.
reduces the rate of products that do not qualify for
shipment.
Quality control and quality assurance activities serve
different objectives.

21. METHODS OFSOFTWAREQUALITYCONTROL
SQCinvolves overseeing the software development process to ensure that the
procedures and STD’s are being followed
The following activities constitute SQC:
Quality Reviews -in-process reviews of processes and products
Reviews are the most widely used method of validating the quality of processes
and products.
Reviews make quality everyone's responsibility.
Quality must be built-in. SQE is responsible for writing Quality Engineering
Records (QERs) documenting their participation in these reviews.
Tests -end-result verifications of products. These verifications are conducted
after the software has been developed.
Test procedures are followed during conduct of these activities. SQE is
responsible for keeping the logs and some times for writing the test report.
Quality Audits -in-process verifications of processes.
These audits are conducted periodically (twice a month) to assess compliance to
the process STD’s.

22. QUALITYREVIEWS
Peerreviews-reviewsofprocessesandproductsbygroupsof
people.
Thesereviewsrequirepre-reviewpreparationbyallparticipants.
Ifaparticipantisnotprepared,thenthereviewisnoteffective.
ThistypeofreviewrequiresparticipationoftheSQE,moderator,
recorder,author(s),andoneormorecriticalreviewers.
AllissuesfoundduringthesereviewsaredocumentedonARforms.
Walkthroughs-reviewsofproductsbygroupsofpeoplemostly
withoutpreparation.
Forexamplearequirementstraceabilityreviewisawalkthrough.
Itinvolvestracingarequirementfromcustomerrequirementstothe
testprocedures.
AllissuesfoundduringthesereviewsaredocumentedonCARforms.
Deskinspections-reviewsofproductsbyindividuals.
Thesereviewsinvolvepeoplereviewingproductsbythemselves(not
inagroup)andthensubmittingtheircommentstotheauthor(s).
Theissuesfoundduringthesereviewsaretreatedininformal
manner.

23. TESTS
Engineering Dry-run-test conducted by engineering without SQE.
These tests include Unit Tests and engineering dry-runs of the formal tests.
These engineering dry-runs are used to verify correctness and completeness of the
test procedures.
Also, these is the final engineering verification of the end-product before sell-off to
SQE.
All issues found during these tests are documented on STR forms.
SQE Dry-run-test conducted by SQE.
These tests include PQT, FAT and SAT dry-runs.
These tests are used to verify the end-product before the formal test with the
customer.
An SQE is sometimes responsible for writing the test report.
However, if a separate test group is available, then SQE is relived of this obligation.
All issues found during these tests are documented on STR forms.
TFR-test conducted as “RFR -run-for-record” with the SQE and the
customer.
These tests include FAT and SAT.
These tests are conducted to sell the end-product off to the customer.
SQE is present at all such tests.
All issues found during these tests are documented on STR forms.

24. QUALITYAUDITS
SQE Audits-audits conducted by SQE to verify that the process STD’s are
being followed.
Examples of these audits are IPDS compliance, Configuration Control, and
Software Engineering Management.
All findings for these audits are documented on QER forms.
The results of the audits are distributed to the next level of management
(above project level).
If the issue(s) are not fixed then the findings are elevated to upper
management.
Independent Audits-audits conducted by ISO generalists or other
independent entities to verify that the process STD’s are being followed.
These audits are usually conducted on a division/facility level.
The results of these audits are distributed to upper management.

25. SOFTWARECONFIGURATION MANAGEMENT
SCM–activitiesassuringthatsoftwareproductsareproperly
identifiedandtheirtransitionistracked.
InmanymatureorganizationsSCMisnotpartofSQA
responsibilities.
•BaselineIdentification–identificationofinitialstateofthe
product
•ChangeIdentification–identificationofchangesmadeto
thebaseline
•ChangeControl–documentationofchangesviarevision
history,changesummary,orusingautomateddevelopmenttools
(ClearCaseorApex)
•StatusAccounting–reportingchangestoothersand
monitoringcompletenessoftheprojectarchives
•Preservation–keeperofthesoftwareproducts

26. Software quality challenges
1. Defining it
2. Describing it (qualitatively)
3. Measuring it (quantitatively)
4. Achieving it (technically)

27. SOFTWAREQUALITYMETRICS
27

28. METRICSCOLLECTION
Softwaremeasurement-theprocessofderivinganumericvalueforsome
attributeofasoftwareproductorasoftwareprocess.
ComparisonofthesevaluestoeachotherandtoSTD’sallowsdrawing
conclusionsaboutthequalityofsoftwareproductsortheprocess.
•Thefocusofthemetricscollectingprogramsisusuallyoncollectingmetricson
programdefectsandtheV&Vprocess.
•MetricscanbeeitherControlMetricsorPredictorMetrics
•Mostofthe“Ilities”cannotbemeasureddirectlyunlessthere’shistoricaldata.
Insteadtangiblesoftwareproductattributesaremeasuredandthe
•“Ility”factorsarederivedusingpredefinedrelationshipsbetweenmeasurable
andsyntheticattributes.
•Theboundaryconditionsforallmeasurementsshouldbeestablishedinadvance
andthenrevisedoncealargedatabankofhistoricaldatahasbeenestablished

29. THEPROCESSOFPRODUCTMEASUREMENT
29
1. Decide what data is to be collected
2. Assess critical (core) components first
3. Measuring component characteristics might require automated tools
4. Look for consistently (unusuallyonly works in a factory) high or low values
5. Analysis of anomalous components should reveal if the quality of product is
compromised

30. PREDICTOR ANDCONTROLMETRICS
30
Examples of Predictor Analysis:
• Code Reuse: SLOC = ELOC = Ported Code
• Nesting Depth: ND > 5 = Low Readability
• Risk Analysis: # STR P1 > 0 at SAT = Low Product Reliability
Examples of Control Analysis:
• STR aging: Old STRs = Low Productivity
• Requirements Volatility: High Volatility = Scope Creep

31. SOFTWAREPRODUCTMETRICS
Therearetwocategoriesofsoftwareproductmetrics:
1.Dynamicmetrics–thismetricsiscollectedbymeasuring
elementsduringprogram’sexecution.
Thismetricshelptoassesefficiencyandreliabilityofa
softwareproduct.
Theparameterscollectedcanbeeasilymeasured(i.e.
executiontime,meantimebetweenfailures)
2.Staticmetrics–thismetricsiscollectedbymeasuring
parametersoftheendproductsofthesoftwaredevelopment.
•Thismetricshelptoassesthecomplexity,understandability,
andmaintainabilityofasoftwareproduct.
•TheSLOCsizeandNDarethemostreliablepredictorsof
understandability,complexity,andmaintainability.

32. 32
THEILITIES
The specific metrics that are relevant
depend on the on the project, the
goals of the SQA, and the type of SW
that is being
developed.

33. DEFECTPREVENTION
Defect Prevention–establishment of practices that lower the reliance on defect detection
techniques to find majority of the bugs
• Lessons learned–learning from other peoples experiences and sharing own
experiences with the other projects
• Managing With Metrics–collecting the metrics, understanding it, and making
changes to the product or process based on analysis.
• Metrics must be standardizedto be effective.
• Risk Analysis–identifying potential risks and opportunities early in the
program and tracking them to realization.
• Build freeze–no changes are made to the code during formal tests.
• Unit-level testing guidelines–test plans and procedures for each UT
• Baseline acceptance criteria–establishment of closure criteria in advance
(i.e. no P1 STRs at FAT TRR)

34. COSTOFQUALITY(COQ)
It is defined as a methodology that allows an organization to
determine the extent to which its resources are used for
activities that prevent poor quality, that appraise the quality of
the organization's products or services, and that result from
internal and external failures.
Basically, the costs of software quality (COSQ) arethose costs
incurred through both meeting and not meeting the customer's
quality expectations.
In other words, there are costs associated with defects, but
producing a defect-free product or service has a cost as well
34

35. The cost of poor quality affects:
Internal and external costs resulting from failing to meet
requirements.
The cost of good quality affects:
Costs for investing in the prevention of non-conformance to
requirements.
Costs for appraising a product or service for conformance to
requirements.

37. CATEGORIES TOMEASURE COSTOFQUALITY
1.Prevention costsinclude cost of training developers on
writing secure and easily maintainable code
2.Detection costsinclude the cost of creating test cases,
setting up testing environments, revisiting testing
requirements.
3.Internal failure costsinclude costs incurred in fixing
defects just before delivery.
4.External failure costsinclude product support costs
incurred by delivering poor quality software.
37

38. INTERNALFAILURECOSTS
Examples include the costs for:
Rework
Delays
Re-designing
Shortages
Failure analysis
Re-testing
Downgrading
Downtime
Lack of flexibility and adaptability

39. EXTERNALFAILURECOSTS
Examples include the costs for:
Complaints
Repairing goods and redoing services
Warranties
Customers’ bad will
Losses due to sales reductions
Environmental costs

40. PREVENTION COSTS
Examples include the costs for:
Quality planning
Supplier evaluation
New product review
Error proofing
Capability evaluations
Quality improvement team meetings
Quality improvement projects
Quality education and training

41. APPRAISALCOSTS
Examples include the costs for:
Checking and testing purchased goods and services
In-process and final inspection/test
Field testing
Product, process or service audits
Calibration of measuring and test equipment

42. QUALITYMODEL
SoftwareQualityModelsareaStandardizedwayof
measuringasoftwareproduct.
Withtheincreasingtrendinsoftwareindustry,new
applicationsareplannedanddevelopedeveryday.
Thiseventuallygivesrisetotheneedforreassuringthat
theproductsobuiltmeetsatleasttheexpectedstandards
42

43. TYPESOFSOFTWAREQUALITYMODELS
1.McCallModel
DevelopedbytheRomeairdevelopmentcenter(RADC),theUSair-force
electronicsystemdecision(ESD),generalelectric,inordertoimprovethe
qualityofsoftwareproductsatsoftwaredevelopmentcompanies.
Themodelwasdevelopedtoassesstherelationshipsbetweenexternal
factorsandproductqualitycriteria.
Thequalitycharacteristicswereclassifiedinthreemajortypes,eleven
suchfactorswhichdescribetheexternalviewofthesoftware(userview),
23qualitycriteriawhichdescribetheinternalviewofthesoftware
(developerview),andthemetricswhichdefineandareusedtoprovidea
scaleandmethodformeasurement.
Thetotalnumberoffactorswasreducedtoeleveninordertosimplifyit.
ThosefactorsareCorrectness,Integrity,Reliability,Efficiency,Usability,
Flexibility,Maintainability,Reusability,Testability,Portability,and
Interoperability.
Themajorcontributionofthismodelistherelationshipbetweenthe
qualitycharacteristicsandmetrics.But,thismodeldoesnotconsider
directlyonthefunctionalityofsoftwareproducts.

44. classifies all software requirements into 11 software
quality factors.
The 11 factors are grouped into three categories –
product operation, product revision and
product transition –as follows:
Product Operation Factors
How well it runs….
Correctness, reliability, efficiency, integrity, and usability
Product Revision Factors
How well it can be changed, tested, and redeployed.
Maintainability;flexibility;testability
Product Transition Factors
How well it can be moved to different platforms and interface
with other systems
Portability;Reusability;Interoperability

45. Software quality factors
Product operation factors
Product revision factors
Product transition factors
McCall's software quality factors model
45

46. 2.BoehmModel
BoehmaddednewfactorstoMcCall’smodelwithemphasis
onthemaintainabilityofsoftwareproductatsoftware
developmentcompanies.
Themainaimofthismodelistoaddressthecontemporary
shortcomingsofmodelsthatautomaticallyand
quantitativelyevaluatethequalityofsoftware.
Boehmmodelrepresentsthecharacteristicsofthesoftware
producthierarchicallyinordertogetcontributeinthetotal
quality.
Also,thesoftwareproductevaluationconsideredwith
respecttotheutilityoftheprogram.
But,thismodelcontainsonlyadiagramwithoutany
suggestionaboutmeasuringthequalitycharacteristics.

47. 3.FURPSModel
FURPSmodelwasproposedbyandHewlett-PackardCoand
RobertGrady.
Theattributeswereclassifiedintotwomaincategoriesaccording
totheuser’srequirements,thefunctionalandnon-functional
requirements.
Functionalrequirements(F):Definedbyinputandexpected
output.
Non-functionalrequirements(URPS):
Usability,reliability,performance,supportability.Also,thismodel
wasextendedbyIBMRationalSoftware–intoFURPS+.
Thus,thismodelconsideredonlytheuser’srequirementsand
disregardsthedeveloperconsideration.
But,thismodelfailstotakeintoaccountthesoftwaresomeofthe
productcharacteristics,likemaintainabilityandportability.

48. 4.DromeyModel
Dromey(1995)statesthattheevaluationisdifferentfor
eachproduct,thusadynamicideaforprocessmodelingis
required.
Thus,themainideaoftheproposedmodelwastoobtaina
modelbroadenoughtoworkfordifferentsystems.
Alsothemodelseekstoincreaseunderstandingofthe
relationshipbetweentheattributes(characteristics)andthe
sub-attributes(sub-characteristics)ofquality.
Alsothismodeldefinedtwolayers,thehigh-levelattributes
andsubordinateattributes.
Therefore,thismodelsuffersfromlackofcriteriafor
measurementofsoftwarequality.

49. 5. ISO IEC 9126 Model
As,manysoftwarequalitymodelswereproposed,the
confusionhappenedandnewstandardmodelwasrequired.
Thus,ISO/IECJTC1begantodeveloptherequired
consensusandencouragestandardizationworld-wide.
TheISO9126ispartoftheISO9000standard,anditisthe
mostimportantstandardforqualityassurance.
Thefirstconsiderationsoriginatedin1978,andintheyear
1985thedevelopmentofISO/IEC9126wasstarted.
Inthismodel,forsoftwaredevelopmentcompanies,the
totalityofsoftwareproductqualityattributeswasclassified
inahierarchicaltreestructureofcharacteristicsandsub
characteristics.
Andthehighestlevelofthisstructureconsistsofthequality
characteristicsandthelowestlevelconsistsofthesoftware
qualitycriteria.

50. Thismodelspecifiedsixcharacteristicsincluding
Functionality,theReliability,Usability,Efficiency,
MaintainabilityandthePortability;allofwhicharefurther
dividedinto21subcharacteristics.
Allthesesubcharacteristicsaremanifestedexternallywhen
thesoftwareisusedaspartofacomputersystem,andthusare
theresultofinternalsoftwareattributes.
Allthedefinedcharacteristicsareapplicabletoeverykindof
software,includingcomputerprogramsanddatacontainedin
firmwareandprovideconsistentterminologyforsoftware
productquality.
Andtheyalsoprovideaframeworkformakingtrade-offs
betweensoftwareproductcapabilities.