Module 5: Validation and Verification

Source PDFs
• class_material/Module_5/software [Link]

Detailed Study Plan

The notes below are comprehensive and include source-aligned extracted content
so that no major topic from the class material is omitted.

Topics Covered
• Testing strategy and testing process
• Component, integration and system testing
• Defect testing and validation testing
• Test case design and automation concepts
• Reviews, inspections, audits and regression testing
• Advanced testing contexts: OO/web/mobile/devops/cloud

High-Value Exam Areas

• Definitions, distinctions, and concept comparisons
• End-to-end process flow explanations
• Scenario-based application and trade-off analysis
• Diagram interpretation and model construction

Diagram Screenshots (Checked)

Screenshots below are selected from content pages after page-level keyword
checks (not only title/task pages).

software [Link] - Page 25

software [Link] - Page 41
software [Link] - Page 47

Source-by-Source Detailed Content

Source: software [Link]
Extracted Topic Map
• Software testing
• Agenda
• • System testing
• • Component testing
• • Test case design

1
Figure 1: software [Link] page 25

2
Figure 2: software [Link] page 41

3
Figure 3: software [Link] page 47

4
 • • Test automation
• The testing process
• – Testing of individual program components;
• – Usually the responsibility of the component developer (except
• sometimes for critical systems);
• – Testing of groups of components integrated to create a system or subsys-
tem;
• – The responsibility of an independent testing team;
• Testing phases
• Component
• testing
• System
• Software developer
• Independent testing team
• Defect testing
• • The goal of defect testing is to discover defects
• in programs
• • A successful defect test is a test which causes a
• program to behave in an anomalous way
• • Tests show the presence not the absence of
• defects
• Testing process goals
• • Validation testing
• – To demonstrate to the developer and the system customer that the
• software meets its requirements;
• • Defect testing
• – To discover faults or defects in the software where its behaviour is
• incorrect or not in conformance with its specification;
• – A successful test is a test that makes the system perform incorrectly
• The software testing process
• Test
• cases
• Design test
• data
• Prepar e test
• results

Full Source Extract (Verbatim from PDF text extraction) Expand

full extracted text
Software testing

Agenda
• System testing
• Component testing
• Test case design

5
• Test automation

The testing process

• Component testing
– Testing of individual program components;
– Usually the responsibility of the component developer (except
sometimes for critical systems);
– Tests are derived from the developer’s experience.

• System testing
– Testing of groups of components integrated to create a system or subsystem;
– The responsibility of an independent testing team;
– Tests are based on a system specification.

Testing phases

Component
testing

System
testing

Software developer

Independent testing team

Defect testing
• The goal of defect testing is to discover defects
in programs
• A successful defect test is a test which causes a
program to behave in an anomalous way
• Tests show the presence not the absence of
defects

Testing process goals

• Validation testing
– To demonstrate to the developer and the system customer that the
software meets its requirements;
– A successful test shows that the system operates as intended.

• Defect testing
– To discover faults or defects in the software where its behaviour is
incorrect or not in conformance with its specification;
– A successful test is a test that makes the system perform incorrectly
and so exposes a defect in the system.

6
The software testing process

Test
cases

Design test
cases

Test
data

Prepar e test
data

Test
results

Run pr ogram
with test da ta

Test
repor ts

Compar e r esults
to test cases

Testing policies
• Only exhaustive testing can show a program is free
from defects. However, exhaustive testing is
impossible,
• Testing policies define the approach to be used in
selecting system tests:
– All functions accessed through menus should be
tested;
– Combinations of functions accessed through the
same menu should be tested;
– Where user input is required, all functions must be
tested with correct and incorrect input.

System testing
• Involves integrating components to create a
system or sub-system.
• May involve testing an increment to be
delivered to the customer.
• Two phases:
– Integration testing - the test team have access to

7
the system source code. The system is tested as
components are integrated.
– Release testing - the test team test the complete
system to be delivered as a black-box.

Integration testing
• Involves building a system from its
components and testing it for problems that
arise from component interactions.
• Top-down integration
– Develop the skeleton of the system and populate it
with components.

• Bottom-up integration
– Integrate infrastructure components then add
functional components.

• To simplify error localisation, systems should

be incrementally integrated.

Incremental integration testing

A
T1

A
T1

T2

T2
T2

B
T3

B
T3

T3

8
T4
C

T4
D

Test sequence 1

T1

Test sequence 2

Test sequence 3

T5

Testing approaches
• Architectural validation
– Top-down integration testing is better at discovering errors in the
system architecture.

• System demonstration
– Top-down integration testing allows a limited demonstration at an early
stage in the development.

• Test implementation
– Often easier with bottom-up integration testing.

• Test observation
– Problems with both approaches. Extra code may be required to observe
tests.

Release testing
• The process of testing a release of a system
that will be distributed to customers.
• Primary goal is to increase the supplier’s
confidence that the system meets its
requirements.
• Release testing is usually black-box or
functional testing
– Based on the system specification only;
– Testers do not have knowledge of the system
implementation.

Black-box testing
Input test da ta

9
Ie

Inputs causing
anomalous
beha viour

Oe

Outputs w hich r eveal

the pr esence of
defects

System

Output test r esults

Testing guidelines
• Testing guidelines are hints for the testing team to
help them choose tests that will reveal defects in the
system
– Choose inputs that force the system to generate all
error messages;
– Design inputs that cause buffers to overflow;
– Repeat the same input or input series several times;
– Force invalid outputs to be generated;
– Force computation results to be too large or too
small.

Testing scenario
A student in Scotland is studying American History and has been asked to write a paper
on ÔFrontier mentality in the American West from 1840 to 1880Õ.To do this, she needs to
find sources from a range of libraries. She logs on to the LIBSYS system and uses the
search facility to discover if she can access original documents from that time. She
discovers sources in various US university libraries and downloads copies of some of
these. However, for one document, she needs to have confirmation from her university
that she is a genuine student and that use is for non-commercial purposes. The student
then uses the facility in LIBSYS that can request such permission and registers her
request. If granted, the document will be downloaded to the registered libraryÕs server
and printed for her. She receives a message from LIBSYS telling her that she will receive
an e-mail message when the printed document is available for collection.

System tests
1. Test the login mechanism using correct and incorrect logins to check
that valid users are accepted and invalid users are rejected.
2. Test the search facility using different queries against known sources to

10
check that the search mechanism is actually finding documents.
3. Test the system presentation facility to check that information about
documents is displayed properly.
4. Test the mechanism to request permission for downloading.
5. Test the e-mail response indicating that the downloaded document is
available.

Use cases
• Use cases can be a basis for deriving the tests
for a system. They help identify operations to
be tested and help design the required test
cases.
• From an associated sequence diagram, the
inputs and outputs to be created for the tests
can be identified.

Collect weather data sequence chart

:CommsController

:WeatherStation

request (repor t)
acknowledge ()

repor t ()
summarise ()

send (repor t)
reply (repor t)
acknowledge ()

:WeatherData

Performance testing
• Part of release testing may involve testing the
emergent properties of a system, such as
performance and reliability.
• Performance tests usually involve planning a
series of tests where the load is steadily
increased until the system performance
becomes unacceptable.

Stress testing
• Exercises the system beyond its maximum design load.
Stressing the system often causes defects to
come to light.

11
• Stressing the system test failure behaviour.. Systems should
not fail catastrophically. Stress testing checks for unacceptable
loss of service or data.
• Stress testing is particularly relevant to distributed systems that
can
exhibit
severe
degradation
as
a
network becomes overloaded.

Component testing
• Component or unit testing is the process of
testing individual components in isolation.
• It is a defect testing process.
• Components may be:
– Individual functions or methods within an object;
– Object classes with several attributes and methods;
– Composite components with defined interfaces
used to access their functionality.

Object class testing

• Complete test coverage of a class involves
– Testing all operations associated with an object;
– Setting and interrogating all object attributes;
– Exercising the object in all possible states.

• Inheritance makes it more difficult to design

object class tests as the information to be
tested is not localised.

Weather station object interface

WeatherStation
identifier
repor tWeather ()
calibrate (instruments)
test ()
star tup (instruments)
shutdown (instruments)

Weather station testing

• Need to define test cases for reportWeather,
calibrate, test, startup and shutdown.
• Using a state model, identify sequences of
state transitions to be tested and the event

12
sequences to cause these transitions
• For example:
– Waiting -> Calibrating -> Testing -> Transmitting
-> Waiting

Interface testing
• Objectives are to detect faults due to interface
errors or invalid assumptions about interfaces.
• Particularly important for object-oriented
development as objects are defined by their
interfaces.

Interface testing
Test
cases

Interface types
• Parameter interfaces
– Data passed from one procedure to another.

• Shared memory interfaces

– Block of memory is shared between procedures or functions.

• Procedural interfaces
– Sub-system encapsulates a set of procedures to be called by other subsystems.

• Message passing interfaces

– Sub-systems request services from other sub-system.s

Interface errors
• Interface misuse
– A calling component calls another component and makes an error in its
use of its interface e.g. parameters in the wrong order.

• Interface misunderstanding
– A calling component embeds assumptions about the behaviour of the
called component which are incorrect.

• Timing errors
– The called and the calling component operate at different speeds and

13
out-of-date information is accessed.

Interface testing guidelines

• Design tests so that parameters to a called procedure are at the
extreme ends of their ranges.
• Always test pointer parameters with null pointers.
• Design tests which cause the component to fail.
• Use stress testing in message passing systems.
• In shared memory systems, vary the order in which
components are activated.

Test case design

• Involves designing the test cases (inputs and
outputs) used to test the system.
• The goal of test case design is to create a set of
tests that are effective in validation and defect
testing.
• Design approaches:
– Requirements-based testing;
– Partition testing;
– Structural testing.

Requirements based testing

• A general principle of requirements
engineering is that requirements should be
testable.
• Requirements-based testing is a validation
testing technique where you consider each
requirement and derive a set of tests for that
requirement.

Partition testing
• Input data and output results often fall into
different classes where all members of a class
are related.
• Each of these classes is an equivalence
partition or domain where the program
behaves in an equivalent way for each class
member.
• Test cases should be chosen from each
partition.

Equivalence partitioning

Invalid inputs

14
Valid inputs

System

Outputs

Examples
• Let's consider the behavior of Order Pizza Text Box Below
• Pizza values 1 to 10 is considered valid. A success message is
shown. While value 11 to 99 are considered invalid for order
and an error message will appear, "Only 10 Pizza can be
ordered"

Cont…
• Password field should be 6 to maximum 10
• Equivalence partitioning
• Valid
6 to 10 characters
Invalid
0 to 5 , from 11 onwards
Boundary value

Equivalence partitions
3

Less than 4

11
10

Betw een 4 and 1 0

More than 1 0

Number of input v alues

9999
10000

Less than 1 0000

Input v alues

50000

15
100000
99999

Betw een 1 0000 and 99999

More than 99999

Search routine specification

procedure Search (Key : ELEM ; T: SEQ of ELEM;
Found : in out BOOLEAN; L: in out ELEM_INDEX) ;
Pre-condition
-- the sequence has at least one element
T’FIRST <= T’LAST
Post-condition
-- the element is found and is referenced by L
( Found and T (L) = Key)
or
-- the element is not in the array
( not Found and
not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))

Search routine - input partitions

• Inputs which conform to the pre-conditions.
• Inputs where a pre-condition does not hold.
• Inputs where the key element is a member of
the array.
• Inputs where the key element is not a member of the
array.

Testing guidelines (sequences)

• Test software with sequences which have only a
single value.
• Use sequences of different sizes in different tests.
• Derive tests so that the first, middle and last elements
of the sequence are accessed.
• Test with sequences of zero length.

Search routine - input partitions

Sequence
Single value
Single value
More than 1 value
More than 1 value
More than 1 value

16
More than 1 value
Input sequence (T)
17
17
17, 29, 21, 23
41, 18, 9, 31, 30, 16, 45
17, 18, 21, 23, 29, 41, 38
21, 23, 29, 33, 38

Element
In sequence
Not in sequence
First element in sequence
Last element in sequence
Middle element in sequence
Not in sequence
Key (Key )
17
0
17
45
23
25

Output (Found, L)
true, 1
false, ??
true, 1
true, 7
true, 4
false, ??

Structural testing
• Sometime called white-box testing.
• Derivation of test cases according to program
structure. Knowledge of the program is used to
identify additional test cases.
• Objective is to exercise all program statements
(not all path combinations).

Structural testing
Test da ta

Tests

Deri ves

17
Component
code

Test
outputs

Binary search - equiv. partitions

• Pre-conditions satisfied, key element in array.
• Pre-conditions satisfied, key element not in
array.
• Pre-conditions unsatisfied, key element in array.
• Pre-conditions unsatisfied, key element not in array.
• Input array has a single value.
• Input array has an even number of values.
• Input array has an odd number of values.

Binary search equiv. partitions

Equivalence class boundaries

Elements < Mid

Elements > Mid

Mid-point

Binary search - test cases

Input array (T)
17
17
17, 21, 23, 29
9, 16, 18, 30, 31, 41, 45
17, 18, 21, 23, 29, 38, 41
17, 18, 21, 23, 29, 33, 38
12, 18, 21, 23, 32
21, 23, 29, 33, 38

Key (Key)
17
0
17
45
23
21
23
25

18
Output (Found, L)
true, 1
false, ??
true, 1
true, 7
true, 4
true, 3
true, 4
false, ??

Path testing
• The objective of path testing is to ensure that the set
of test cases is such that each path through the
program is executed at least once.
• The starting point for path testing is a program flow
graph that shows nodes representing program
decisions and arcs representing the flow of control.
• Statements with conditions are therefore nodes in the
flow graph.

Binary search flow graph

1

bottom > top

while bottom <= top

7
elemArray
[mid] = key

11

elemArray [mid] > key

8

19
9

14

elemArray [mid] != key

10

12

elemArray [mid] < key

13

Independent paths
• 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14
• 1, 2, 3, 4, 5, 14
• 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, …
• 1, 2, 3, 4, 6, 7, 2, 11, 13, 5, …
• Test cases should be derived so that all of these
paths are executed
• A dynamic program analyser may be used to
check that paths have been executed

Formula
• Cyclomatic complexity = E - N + 2*P where,
E = number of edges in the flow graph. N =
number of nodes in the flow graph. P =
number of nodes that have exit points

Cont.…

Cont…

Test automation
• Testing is an expensive process phase. Testing workbenches
provide a range of tools to reduce the time required and total
testing costs.
• Systems such as Junit support the automatic execution of tests.
• Most testing workbenches are open systems because testing
needs are organisation-specific.
• They are sometimes difficult to integrate with closed design
and analysis workbenches.

A testing workbench
Test da ta
gener ator

20
Specification

Sour ce
code

Test
mana ger

Test da ta

Oracle

Dynamic
anal yser

Program
being tested

Test r esults

Test
predictions

Execution
repor t

Simulator

File
comparator

Repor t
gener ator

Test r esults
repor t

Testing workbench adaptation

• Scripts may be developed for user interface
simulators and patterns for test data generators.
• Test outputs may have to be prepared manually
for comparison.
• Special-purpose file comparators may be
developed.

21
Key points
• Testing can show the presence of faults in a system; it cannot
prove there are no remaining faults.
• Component developers are responsible for component testing;
system testing is the responsibility of a separate team.
• Integration testing is testing increments of the system; release
testing involves testing a system to be released to a customer.
• Use experience and guidelines to design test cases in defect
testing.

Key points
• Interface testing is designed to discover defects in the
interfaces of composite components.
• Equivalence partitioning is a way of discovering test cases all cases in a partition shoul
• Structural analysis relies on analysing a program and
deriving tests from this analysis.
• Test automation reduces testing costs by supporting the
test process with a range of software tools.

Cont.…

Cont.…

Cont…
• [Link]

Extended Testing and V&V Deep Dive

A. Verification vs Validation
Verification asks: “Are we building the product right?” Validation asks: “Are
we building the right product?”
Both are necessary: - Verification improves engineering correctness. - Validation
ensures user/business relevance.

B. Defect Lifecycle Awareness

A typical defect journey: 1. Detection 2. Logging and classification 3.
Triage/prioritization 4. Fix implementation 5. Re-test 6. Regression check 7.
Closure
Defect severity and priority are different: - Severity = technical/business impact
- Priority = urgency of fix order

22
C. Strong Test Strategy Construction
A high-quality test strategy addresses: - Scope in/out - Levels of testing - Envi-
ronment setup - Data preparation - Entry/exit criteria - Risk-based prioritiza-
tion - Automation approach - Reporting metrics

D. Test Design Techniques (Important)

• Equivalence partitioning
• Boundary value analysis
• Decision table testing
• State transition testing
• Error guessing
Good exam answers include one example per technique.

E. Regression and Mutation Testing

Regression testing confirms existing behavior remains stable after changes. Mu-
tation testing evaluates test suite strength by introducing small code changes
and checking if tests fail as expected.

F. Reviews, Inspections and Audits

Static quality practices catch defects early: - Reviews: collaborative quality
checks - Inspections: formal defect-focused analysis - Audits: compliance and
process adherence checks
Early defect detection drastically reduces correction cost.

G. Modern Testing Contexts

• Web testing: browser compatibility, responsiveness, security.
• Mobile testing: device diversity, network variability, battery/performance.
• DevOps testing: continuous pipeline integration.
• Cloud testing: scalability, reliability, distributed behavior.

H. Examination-Ready Framing
For long answers: - Define testing goals. - Explain phases and responsibilities. -
Explain design methods and static testing. - Explain regression and automation
value. - Explain modern testing challenges.

Enhanced Diagram Gallery (Verified)

This gallery is generated by a stricter two-stage detector: - Visual page analysis
(connected-component/shape heuristics) + keyword scoring. - Direct embedded-
image extraction from PDF with size filtering.

23
A) Diagram-like Pages (Rendered)
software [Link]

• Page 7

• Page 14

24
• Page 18

• Page 35

25
 • Page 47

• Page 54

B) Embedded Figures (Directly Extracted)

• No large embedded figures found (likely vector-drawn diagrams in slides).

26