SWE2005-SOFTWARE TESTING

Verification and Validation Testing

Module 4

Dr. Shivani Gupta,

VIT Chennai
 2

OUTLINE
▪ Introduction to Verification and Validation Testing
▪ Verification Testing(Static Testing)
▪ Inspection
▪ Structured walkthrough
▪ Technical reviews
▪ Validation Testing
▪ Unit testing
▪ Integration testing
▪ System testing
▪ Acceptance testing
▪ System testing
 Introduction to Verification Testing
▪ Verification is the process of checking that a software achieves its goal
without any bugs.
▪ It is the process to ensure whether the product that is developed is right
or not.
▪ It verifies whether the developed product fulfills the requirements that
we have. Verification is static testing.
▪ Verification means Are we building the product right?
Introduction to Validation Testing
▪ Validation is the process of checking whether the software
product is up to the mark or in other words product has high
level requirements.
▪ t is the process of checking the validation of product i.e. it checks
what we are developing is the right product.
▪ It is validation of actual and expected product. Validation is the
dynamic testing.
▪ Validation means Are we building the right product?
 Inspection
▪ Inspections are conducted by a team of four to six members for any
model development work product such as requirements specification,
design specification, or code.

▪ The team consists of:

▪ Author
▪ Inspector
▪ Moderator
▪ Recorder
Inspection Phases
An inspection goes through six distinct phases:

1.Planning

2. Overview:

3. Individual Preparation

4. Inspection meeting

5. Rework:

6. Follow-up:
Structured Walkthroughs
▪ The Walkthrough Team consists of a moderator, model developer,
and 3 to 6 other members.
▪ Except the model developer, all other members should not be
directly involved in the model development effort.
Roles of the team members in a structured
walkthrough:
▪ Presenter: most often is the model developer.
▪ Coordinator: Organizes, moderates, and follows up the walkthrough activities. Is usually from
the SQA department.
▪ Scribe: Documents the events of the meeting.
▪ Maintenance Oracle: Considers long-term implications.
▪ Standards Bearer: Concerned with adherence to standards.
▪ User Representative: Reflects the needs and concerns of the sponsor.
▪ Other Reviewers: (e.g., auditors)
▪ The presenter provides test data and leads the team through a manual
simulated execution of the model system.
▪ The test data are walked through the system.
▪ The purpose is to encourage discussions. Most errors are discovered by
questioning the developer's decisions at various stages.
Technical Review
▪ The review is conducted in a similar manner as the inspection and
walkthrough except in the way the team members are selected.  The
review team also involves managers.
▪ The review is intended to:
▪ give management and the sponsor evidence that the model development
process is being carried out according to stated requirements and project
objectives.
▪ evaluate the model in light of development standards, guidelines, and
specifications.
As such, the review is a higher level technique than the inspections and
walkthroughs.
▪ Each review team member examines the model documentation prior to
the review.
▪ The team then meets to evaluate the model relative to specifications
and standards, recording defects and deficiencies.
▪ The result of the review is a document portraying the events of the
meeting, deficiencies identified, and review team recommendations.
▪ Appropriate action may then be taken to correct any deficiencies.
▪ As opposed to inspections and walkthroughs, which concentrate on
correctness assessment, reviews seek to ascertain that tolerable levels
of quality are being attained.
The Four Levels of Software Testing

▪ SOFTWARE TESTING LEVELS are the different

stages of the software development lifecycle where
testing is conducted.
▪ There are four levels of software testing:

Unit >> Integration >> System >> Acceptance.

12
Unit Testing
▪ A level of the software testing process where individual units of a
software are tested.
▪ The purpose is to validate that each unit of the software performs
as designed.
 14

Unit testing

 Also called as component, module, program testing

 Verifies functioning of a module.

 Stubs, drivers are used to replace the missing software and

simulate the interface between the components.
 15

Stubs and Drivers

▪ Stub: Dummy procedure, module or

unit that stands in for an unfinished
portion of a system.

▪ Driver : Piece of code that passes test

cases to another piece of code
Unit Testing Methods

It can be performed in 2 ways :

▪ Manual Testing
▪ Automated Testing
▪ In Manual Testing, the tester manually executes test cases without using any
automation tool. Here, each stage of the test is executed manually. Manual
Testing is tedious especially for tests that are repetitive and requires more effort
to create and execute test cases. Manual Testing does not require knowledge of
any testing tool.

▪ In Automated Testing, software testing automation tools are used to automate

the tests/test cases. The automation tool can record and save your test and it
can be re-played as many times as needed without any further human
intervention.
Integration Testing
▪ A level of the software testing process where individual units are
combined and tested as a group.
▪ The purpose of this level of testing is to expose faults in the
interaction between integrated units.
 19

Types of Integration Testing

 Top down integration

 Bottom up integration
 20

Top-Down Integration
test
▪ Incremental strategy
main 1. Start by including highest
level modules in test set.
test
▪ All other modules
main, A, replaced by stubs or
B,C mock objects.
2. Integrate modules called by
called by modules in test set.
test
main, A, B, C 3. Repeat until all modules in
D, E, F test set.
Top-Down Integration 21

test main
main
A B C

test
D E F
main, A, C

test ▪ The integration order can

main, A, be modified to:
C, D, E, F
▪ include critical
test
modules first
main, A, B, C ▪ leave modules not
D, E, F ready to later
 22

Top-Down Integration
▪ Advantages
▪ Fault localization easier
▪ Few or no drivers needed
▪ Different order of testing/implementation possible
▪ Major design flaws found first

▪ Disadvantages
▪ Need lot of stubs
▪ Reusable modules tested inadequately .
 Bottom-up Integration 23

main ▪ Incremental strategy

▪ Test low-level modules, then
A B C
▪ Modules calling them until
D E F highest level module
test
D test
D,E,A
test test
test
E main, A, B,
B
C
test test D, E, F
F C,F
Bottom-up Integration
24

▪ Advantages
▪ Fault localization easier (than big-bang)
▪ No need for stubs
▪ Logic modules tested thoroughly
▪ Testing can be in parallel with implementation
▪ Dis-advantages
▪ Need drivers
▪ High-level modules tested in the last
System testing
25

▪ Is concerned with the behavior of the whole product

▪ It includes tests based on requirement specification, business

processes , high level description of the system behavior.

▪ Should investigate both functional and non-functional

requirements of the system.
Categories of System Testing
▪ Reliability Testing
▪ Security Testing
▪ Performance Testing
▪ Load Testing
▪ Stress Testing
▪ Usability Testing
Acceptance Testing
▪ A level of the software testing process where a system is tested for
acceptability.
▪ The purpose of this test is to evaluate the system’s compliance
with the business requirements and assess whether it is
acceptable for delivery.
Types of Acceptance Testing
▪ Alpha Testing
▪ Beta Testing