SQA:

Software quality assurance (SQA) is a

product complies with apredetermined setmethodology to ensure that the quality of the
of standards. software
What are the principles of software
quality assurance?
Principles of software quality assuranco

Defect
prevention Continuous stakeholdpr
improvement Risk-based
invovemant aPproach

* TURING

Defect prevention: It is always better to prevent defects and errors in

product than to correct them later. And so, the first principle the software
of SQA emphasizes the
importance of identifying and addressing potential issues early in the software
development lifecycle. Unlike quality control, SQA focuses on fixing the root cause of
defects and errors, and not just the symptoms.
Continuous improvement: Here's the thing: SQA is nct a one-time thing. It is more like
an ongoing process youneed to integrate into your software development lifecycle.
other words, the second principle, i.e., continuous improvement underlines the need Into
consistently monitorand improve the quality of the software product.
Stakeholder involvement: SQA must involve all stakeholders in the software
development process, including customers, developers, testers, QA team leads, and
project managers. Andthus, this third principle talks about the importance of
collaboration and communication between the involved parties to ensure a smooth
software development process.
Risk-based approach: Last but not least, SQA mustfocus on identifying and addressing
the most significant risks in the software product. Simply put, this principle emphasizes
the importance of prioritizing risks based on their potentia' impact on the software
product.
 (3)
to

How to implement software quality assurance? (4)

assurance?

quality
How to implement software

P l a n S G A a c t i v i t i e s

Oefine quality standards

Perform testig

Conduct revËews

I m p r o v ec o n t i n u o u s y

Monitor and measure

To
can followthe
* | * TURING
approach. You
implement SQA effectively, it is essential to follow a structured
below-mentioned steps to implement SQA:
product
quality standards: Clearly define the quality standards that your software
I: Detine acceptance criteria, and pertormance
must meet. This includes defining requirements. stakeholders, including the
metrics. These standards should be agreed upon by all
development team, management, and customers.
2. Plan SQA activities: Develop a plan for the SQA activitiesshouldthat willbe performed
include reviews,
throughout the software development life cycle. This plan for
testing, anddocumentation activities. It should also specify who will be responsible
each activity and when it will be performed.
3. Conduct reviews: Conduct reviewS of software artifacts such as requirements, design
documents, and code. These reviews should be conducted by a team of experts who are
not directly involved in the development process. This will help identify defects early in
the development process and reduce the cost of fixing them later.
4. Perform testing: Perform different types of testing such as unit testing, integration testing,
system testing, and acceptance testing. Use automated testing toolsto increase efliciency
and reduce the risk of human error.
5. Monitor and measure: Monitor and measure the quality of the software product
throughout the development process. This includes tracking defects, analyzing netries
such as code coverage and defect density, and conducting root cause analysis.
Improve continuously: Continuously improve the SQA process by analyzing the results of the
monitoring and measuring activities. Use this data to identi fy areas for improvement and
implement changes to the SQA process
Formal technical review
Aformal technical review is a software quality assurance activity performed by software
FTR are
engineers (and others). The objectives of the

)to uncover errors in function, logic, or Implementation for any representation of the
software;
its requirements:
(2)to verifythat the software under review meets
2
 that the software has been represented
(4) to achieve software that is developed in a uniformaccording
ensure
(3)to
manner;toandpredefined standards;
more manageable.
(5)to make projects
In addition, the FTR serves as a training ground, enabling junior engineers to observe different
to software analysis, design, and implementation. The
approaches
backup and continuity because a number of people become familiarFTR
withalsoparts
serves to software
of the promote
that they may
not have otherwise seen.

ETR is actually a class of reviews that includes walkthroughs,

reviews and other small group technical assesSments of software. Eachinspections, round-robin
FTR is conducted as a
oeting and will be successful only if it is properly planned, controlled, and attended. In the
t that follow, guidelines similar to those for a walkthroughare
review. presented as a
representative formal technical

The Review Meeting

Regardless of the FTR format that is chosen, every review meeting should abide by the following
constraints:
"Between three and five people (typically) should be involved in the review.
"Advance preparation should occur but should require no more than two hours of work for each
person.
The duration of the review meeting should be less than two hours.
Given these constraints, it should be obvious that an FTR focuses on a specific (and small) part of
the overall software. For example, rather than attempting to review an entire design,
walkthroughs are conducted for each component or small group of components. By narrowing
focus, the FTR has a higher likelihood of uncovering errors.

The focus of the FTR is on a work product (e.g., a portion of a requirements specitication,hasa
detailed component design, a source code listing for a component).
The individual who
that the work product is
developed the work productthe producer-informs the project leader a review leader, who
contacts
complete and that a review is required. The project leader
product materials, and distributes them to
evaluates the product for readiness, generates copiesof
reviewer is expected to spend between one
twoor three reviewers for advance preparation. Each
two hours reviewing the product, making notes, and otherwise becoming familiar with the
and
the product and establishes an agenda for the
work. Concurrently, the review leader also reviews next day.
for the
review meeting, which is typically scheduled
the
meeting is attended by the review leader, all reviewers, and the producer. One of
The review all
takes on the role of the recorder; that is, the individual who records (in writing) agenda
reviewers the
issues raised during the review. The FTR begins with an introduction of
Important
producer. Theproducer then proceeds to "walk through" the work
and a brief introduction by the reviewers raise issues based on their advance preparation.
product, explaining the material, while are discovered, the recorder notes each.
Or errors
When valid problems

3
 product
review, all attendees of the FTR must decide whether to (1) accept the
At the end of the product due to severe errors (once
corrected, another
further modification, (2) reject the been
without
performed), or (3) accept the product provisionally (minor errors have
review must be additional review will be required). The
decision
encountered and must be corrected, but no participation in the review and their
indicating their
made, all FTR attendees complete a sign-off,
concurrence with the reviewteam's findings.

Review Reporting and Record Keeping

issues that have been raised. These
During the FTR, a reviewer (the recorder)actively records all list is produced. Inaddition,
are summarized at the end of the review meeting and a review issues
a formal technical review summary report is completed.
A review report answers three questions:
summary reviewed?
1. What was
2. Who reviewed it?
3. What were the findings and conclusions?

The review summary report is a single page form (with possible attachments). It becomes part of
the project historical record and may be distributed to the project leader and other interested
parties.
The review issues list serves two purposes:
(1) toidentify problem areas within the product and
(2) to serve as an action item checklist that guides the producer as corrections are made. An
issues list isnormally attached to the summary report.
It isimportant to establish a follow-up procedure to ensure that items on the issues list have been
properly corrected. Unless this is done, it is possible that issues raised can fall between the
cracks." One approach is toassign the responsibility for followupto the review leader.
Review Guidelines

Guidelines for the conduct of formal technical reviews must be established in advance.
distributed to all reviewers, agreed upon, and then followed. A review that is uncontrolled can
often be worse that no review at all. The following represents minimum set of guidelines for
formal technical reviews:

1. Review the product, not the producer. An FTR involves people and egos. Conducted
properly, the FTR should leave all participants with a warm feeling of accomplishment.
Conducted improperly, the FTR can take on the aura of an inquisition. Errors should be pointed
out
gently; the tone of the meeting
Snoula be loose and constructive: the intent should not be to embarrass or belittle. The review
Ieader should conduct the review meeting to ensure that the proper tone and attitude are
maintained and should immediately halt a review that has gotten out of control.

. Set an agenda and maintain it. One of the key maladies of meetings of all types is drift. An

4
prthoerduct with the
be kept on track and on schedule. The review leader is chartered
must
FTR
responsibility for maintaining the meeting schedule
and should not be afraid to nudge peopie
when drift sets in.

by a reviewer, there may not be universal

3. Limit debate and rebuttal. When an issue is raised question, the issue should be
agreement on its impact. Rather than spending time debating the
recorded for further discussion off-line.
is 10t
4. Enunciate problemareas, but don't attempt to solve every problem noted. A review
a problem-solving session. The solution of aproblem can often be accomplished by the producer
alone or with the help of onlyone other individual, Problem solving should be postponed until
after the review meeting.
5. Take written notes. It is sonmetimes a good idea for the recorder to make notes on a wall
board, so that wording and priorities can be assessed by other reviewers as information 1s
recorded.

6. Limit the number of participants and insist upon advance preparation. Two heads are
better than one, but 14 are not necessarily better than 4. Keep the number of people involved to
the necessary minimum. However, all review team members must prepare in advance. Written
comments should be solicited by the review leader (providing an indication that the reviewer has
reviewed the material).

7. Develop a checklist for each product that is likely to be reviewed. Achecklist heips the
review leader to structure the FTR meeting and helps each reviewer to focus on important issues.
Checklists should be developed for analysis, design, code, and even test documents.
8. Allocate resources and schedule time for FTRs. For reviews to be effective, they should be
scheduled as a task during the software engineering process. In addition, time should be
scheduled for the inevitable modifications that will occur as the result of an FTR.
9. Conduct meaningful training for all reviewers. To be effective all review
receive some formal training. The training should stress both process-relatedparticipantsshould
issues and the
human psychological side of reviews. Freedman and Weinberg estimate a one-month learning
curve for every 20people who are to participate effectively in reviews.
10. Review your early reviews. Debriefing can be beneficial in uncovering problems
review process itself. The very wih the
first product to be reviewed should be the review guidelines
themselves.
Because many variables (e.g., number of participants, type of work products, timing and length.
specific review approach) have an impact on a successtul review, a software
experiment to determine what approach works best in a local organization should
context. Porter and his colleagues
provide excellent guidance for this type of experimentation