Software Quality Assurance

Lecture # 4

Quality Assurance
 Software Quality Assurance

 Software QA involves monitoring and

improving the entire software
development process, making sure
that any agreed-upon standards and
procedures are followed, and ensuring
that problems are found and dealt
with.

 Software quality assurance is an

umbrella activity that is applied
throughout the software process.
 Software Quality Assurance

 SQA encompasses:

 a quality management approach

 formal technical reviews

 a multi-tiered testing strategy

 measurement and reporting

mechanism
 Software Quality Assurance

Who involves quality assurance activities?

 Software engineers

 Project managers

 Customers

 Sales people

 SQA Team

The SQA Team’s role

 serves as the customer’s in-house representative

 Work with the software engineering team in achieving

high-quality
 SQA Team

 The Software Quality Assurance group can

include the following Professionals

 Testing Manager

 Test Team Lead

 Test Analyst

 Tester

 Independent Test Observer

SQA Team
 SQA Team

 Testing Manager

 The testing manager has the authority to

monitor/administer the organizational aspects of the
testing process on a day-to-day basis and is
responsible for ensuring that the individual testing
projects produce the required products to the
required standard of quality & within the specified
constraints of time, resources and costs.

 Test manager is also responsible for liaison with the

development teams to ensure that they follow the
unit and integration testing approach documented
within the process.

 Test manager is also responsible for liaison with the

Independent Test Observer to receive reports on
testing projects that have failed to follow the testing
process correctly.

 Test manager reports to a senior manager.

 SQA Team

 Testing Team Lead

 The testing team lead is given the authority to run a

testing project.

 His or her responsibility includes tasking one or more

Test Analysts and Testers, monitoring their progress
against agreed –upon plans, setting up and
maintaining the testing project and ensuring the
generation of the testing project artifacts, including:

Test Plan Document, which will be used as a basis of

project management control throughout the testing
process. This document is approved by a testing
manager and sometimes produced by both Testing
Manager and the Team Lead.

Test Specification Document which outlines in

detail the approach to testing the AUT, the resources
needed, the testing environment the evaluation criteria
and so on.
 SQA Team
 Testing Team Lead
 SQA Team

 Testing Analyst

 The testing analyst is responsible for the design and

implementation of test cases which will be used to
accomplish the testing of AUT:

 The Test Analyst may also be called upon to assist the

Team Lead in the generation of test specification
document.
 SQA Team
 Tester

 The tester is responsible for the execution of test cases

created by test analyst or sometimes by tester himself. And
for the interpretation and documentation of the results of the
test cases

 Prior to the execution of the test cases, the Tester will set up
and initialize the test environment, including the test data,
plus any additional software required to support the test.
 SQA Team

 Independent Test Observer

 Independent test observers can be hired or

invited to provide the independent observation of
the testing project

 Independent test observer is responsible for:

 Attending the testing of AUT

 Formally witnessing that the tester
correctly implements all test cases
 Signing the appropriate section of Test
Result Record Form
 Liaising with the Testing manager to
report any problems observed during the
testing process
 SQA Plan

The software quality assurance plan is an outline of quality

measures
to ensure quality levels within a software development effort.

The plan is used to compare the actual levels of quality

during development with the planned levels of quality.

If the levels of quality are not within the planned quality

levels, management will respond appropriately as
documented within the plan.

Basic items:

 purpose of plan and its scope

 Describe the purpose and scope of the document

and indicate those software process activities that
are covered by quality assurance
 SQA Plan

 Management

 organization structure

 SQA tasks and activities and their placement

throughout the software process

 Organizational roles and responsibilities related

to product quality

 Documentation

 Technical documents- e.g specifications, test

plans

 User documents- e.g help files

 SQA Plan

 Standards, practices, and

conventions

 List all applicable standards

and practices that are
applied during the software
process (e.g document
standards, coding
standards)

 All project and process

metrics are listed
 SQA Plan

 Reviews

 Identifies the reviews to be conducted

 Provides an overview of the approach for each review

 Test

 test plan and procedure

 Problem reporting, and Correction actions

 Defines procedures for,

 Reporting
 Resolving errors and defects
 SQA Plan

 Tools

 identifies the tools that

supports SQA tasks and
activities , and

 Identifies the
organizational
responsibilities for these
activities

 Software configuration
management procedures

 Required for controlling

change
 SQA Plan

 Training

 Identifies training required to meet

the needs of the plan

 Risk management

 Defines methods for identifying,

assessing, monitoring and controlling
risk
 Software Reviews

What is software review?

 A “filter” for the software

engineering process.

Why software reviews?

 Humans do mistakes, so
some process is required to
catch the errors.
 Formal Technical Reviews

Objectives of FTR:

 To uncover errors in the artifacts under

review

 To verify the software under review meets

its requirements

 To ensure that the software has been

developed according to predefined
standards
 Formal Technical Reviews

Review meeting’s constraints:

 3-8 people involved in a review

 advanced preparation

 the duration of the review

meeting should be less than or
equal to 2 hours
 Formal Technical Reviews

People involved in a review

meeting:

 Producer

 review leader

 2 or 3 reviewers (one of
them is recorder)
 Formal Technical Reviews

The preparation of a review

meeting:

 a meeting agenda and schedule

(by review leader)

 review material and distribution

(by the producer)

 review in advance (by reviewers)

 Formal Technical Reviews

Review meeting results:

 a review issues list

 a simple review summary report (called

meeting minutes)

 meeting decisions:

 accept the work product w/o further

modification

 reject the work product due to errors

 accept the work under conditions (such as

change and review)

 sign-off sheet
 Formal Technical Reviews

Review summary report answers the

following questions:

 what was reviewed?

 who reviewed it?

 what were the findings and conclusions

Review issues list serves two purposes:

 to identify problem areas in the project

 to serve as an action item checklist (a

follow-up procedure is needed)
 Review Guidelines

A minimum set of guidelines for FTR:

 Review the product, not the producer

 Set an agenda and maintain it

 Limit debate

 Enunciate problem areas, but don’t

attempt to solve every problem noted

 Take written notes

 Limit the number of participants

 Insist upon advance preparation

 Review Guidelines

 Develop a checklist for

each work product that is
likely to be reviewed

 Allocate resources and

time schedule for FTRs

 Conduct meaningful
training for all reviewers