1

CRJ2A3
PENJAMINAN MUTU PERANGKAT LUNAK

VERIFIKASI dan VALIDASI

Tim Dosen SQA KK SE

Program Studi S1 Rekayasa Perangkat Lunak - Universitas

Telkom
 2

OUTLINE

1. Verification and Validation

2. Reviews in SQA
3. Quality Assurance and Quality Control

2
 3

V and V

Verification: Are we building the product right?

Through verification, we make sure the product behaves the way we
want it to.

Validation: Are we building the right product?

Through validation, we check to make sure that somewhere in the
process a mistake hasn’t been made, such that the product build is
not what the customer asked for;
Validation always involves comparison against needs & expectation.

Quality Assurance ensures that verification and validation takes

place.

3
 4

Verification

• Verification is known as static

testing
• Purposes : Ensures that “We
are building the product right“
Checking documents, design, code,
and program in order to check if the
software has been built according to
the specifications or not
• Activities like reviews, walk-
through, inspection

https://www.javatpoint.com/verification-and-validation-testing

4
 5

Validation
• Validation is known as dynamic testing
• Purposes : Ensures that "we have developed the product right“ .
Ensures that the software meets the exact needs of the customer and fulfills
the need desired use in an appropriate environment.
• Activities like unit testing, integration testing, system testing and user
acceptance testing.

5
https://www.javatpoint.com/verification-and-validation-testing
 6

Verification vs. Validation

No Parameters VERIFICATION VALIDATION

1 Process Verification process includes checking of Validation process includes testing and
documents, design, code and program validation of the actual product.
2 Code Verification does not involve code Validation involves code execution.
Execution execution
3 Method is used Verification uses methods like reviews, Validation uses methods like black box
walkthroughs, inspections and desk- testing, white box testing and non-
checking functional testing.
4 Checked Area Verification checks whether the software Validation checks whether the software
confirms a specification meets the requirements and expectations.
5 Finding Defect Verification finds the defects early in the Validation finds the defects that
development cycle verification can not catch.
6 Targets (in SW Verification process targets on software Validation process targets the actual
Testing) architecture, design, database, etc. software product.
7 The team Verification is done by the QA team Validation is done by the involvement of
testing team with QA team.
8 Sequence Verification process comes before Validation process comes after verification.
validation
6
 7

Verification vs. Validation

http://tryqa.com/what-is-validation-in-software-testing-or-what-is-software-validation / 7
 8

Verification and Validation

8
 9

REVIEW in SQA

9
 10

Overview Review

Software reviews are a “filter” for the software process.

• What is it?
– You’ll make mistakes as you develop software engineering work products.
There’s no shame in that—as long as you try hard, very hard, to find and correct
the mistakes before they are delivered to end users. Technical reviews are the
most effective mechanism for finding mistakes early in the software process.
• Why is it important?
– If you find an error early in the process, it is less expensive to correct.
– Reviews save time by reducing the amount of rework that will be required late in
the project.

10
 11

Overview Review (cont.)

• What are the steps?

– Your approach to reviews will vary depending on the degree of formality you
select (informal, formal)
– In general, six steps are employed, although not all are used for every type of
review: planning, preparation, structuring the meeting, noting errors, making
corrections (done outside the review), and verifying that corrections have been
performed properly.
• What is the work product?
– List of issues and/or errors that have been uncovered.
– In addition, the technical status of the work product is also indicated.
• How do I ensure that I’ve done it right?
– First, select the type of review that is appropriate for your development culture.
Follow the guidelines that lead to successful reviews. If the reviews that you
conduct lead to higher quality software, you’ve done it right.

11
 12

Software Reviews by Definitions

• A meeting conducted by technical people for

technical people
• A technical assessment of a work product
created during the software engineering
process
• A software quality assurance mechanism
• A training ground

12
 13

The Review Players

review
leader standards bearer (SQA)

producer

maintenance
oracle

recorder reviewer
user rep

13
 14

Review’s Guidelines

ü Review the product not the producer

ü Set an agenda and maintain it
ü Limit debate and rebuttal
ü Enunciate problem areas, but don’t attempt to solve every problem
ü Take written notes
ü Limit the number of participants and insist on advance preparation
ü Develop a checklist for each work product
ü Allocate resources and time schedule
ü Conduct meaningful training for all reviewers
ü Review earlier reviews

14
 15

Review’s Report

ü Type of Review, Team Members, Date, Time, Place

ü Item being reviewed
ü Agenda
ü Checklist
ü Comments per Checklist item or per Issues list item with
problems mentioned
ü Action per Comment : No action, Fix error, Reconsider
ü Decision for the item being reviewed : Accept, Reject (severe
errors), Accept (minor errors)

15
 16

Walkthrough

• A walkthrough is performed by a team consisting of four to six

people, for example, for the specification walkthrough:
– at least one person from the team that created the specifications, the
technical manager, a client representative, at least one person from the
team for the next activity (design in this case), and a person from the SQA
team (who chairs the meeting)
• The goal of the walkthrough is to find and record faults, not to
correct them

16
 17

Two Ways to Run a Walkthrough

1. Distribute the material well

in advance of the meeting

2. Each reviewer reads it and

prepares two lists: items that
require explanations, and items
that seem incorrect

participant driven: document driven:

4. The representative of the

team that created the document 3. The representative of the
team that created the 4. Each reviewer interrupts as
3. Reviewers present their lists clarifies the items that require needed to bring up an item of
in turn explanations, and either agrees document “walks” through the
that items are incorrect, or concern
document
explains why they are not

17
 18

Inspection
• Inspections are more formal than walkthroughs, they consists of five
steps:

An overview is given by a member of the team that created the document

1

In the preparation step, each participant studies the document, consider lists of faults
2 discovered, and takes notes

The actual inspection meeting begins, with a team member walking through the
3 document, a day after the meeting, the moderator produces a written report

The rework is performed by the team that created the document, to take into account all
4 the items in the report

Finally, in the follow-up, the moderator ensures that every item raised at the meeting has been
resolved. In addition, fixes must be checked to ensure that no new faults have been introduced
5
18
 19

Formal Technical Review (FTR)

• The FTR is actually a class of reviews that includes

walkthroughs and inspections.
• 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 the focus, the FTR has a higher likelihood
of uncovering errors
• Once again, the focus of the FTR is on a work product
(e.g., a portion of a requirements model, a detailed
component design, source code for a component).

19
 20

FTR Output

• At the end of the review, all attendees of the FTR must

decide whether to:
1) accept the product without further modification,
2) reject the product due to severe errors (once corrected, another
review must be performed),
3) or accept the product provisionally (minor errors have been
encountered and must be corrected, but no additional review
will be required).

20
 21

Assurance vs. control

▪ Quality control: detection product

— A set of activities designed to evaluate the quality of
a developed or manufactured product.
— Main objective: withhold any product that does not
qualify.
— Completed before the product is shipped to the client.
▪ Quality assurance: prevention process
— Main objective: minimize the cost of guaranteeing
quality.
— Prevent the cause of errors; detect and correct them
early in the development process
— performed throughout the software life cycle
21
 22

No Parameters Quality Assurance Quality Control

1 Focus Analyze QA is the set of activities using which we QC is the set of activities using which we
analyze the processes used in software analyze the quality of the product build.
development.

2 Process It is a static process of analyzing the It involves dynamic testing of a software

characteristic documents and not the actual end product. product by running it.

3 V and V Verification comes under QA. Validation comes under QC.

relation

4 Objectives It is a preventive measure as it identifies It is a corrective measure as it tests the

the weakness in the process to build built product to find defects.
software to prevent defects.

5 Activities It involves activities like document review, It involves activites like functional testing,
test case review, walkthroughs, inspection automation testing etc.
etc.

6 Team who Carrying out QA activities is the Carrying out QC activities is the
responsible responsibilty of whole team involved in responsibility of testing team, involved in
Software development Life Cycle(SDLC). the Software Testing Life Cycle(STLC).

22
 23

TerimaThank
Kasihyou