SOICT
School of Information and Communication Technology
Software Quality Assurance and
Testing
6 – Software Testing Process
3
Contents
Những nội dung chính
• Software Testing Lifecycle
• System Test Design
• Integration Test
• Regression Test
• Acceptance Test
• Planning and Organization
8/18/25 IT4501 - Software Engineering Department - 4
SoICT/HUST
Process models from waterfall to agile
8/18/25 IT4501 - Software Engineering Department - 5
SoICT/HUST
Phases of testing in the development process
8/18/25 IT4501 - Software Engineering Department - 6
SoICT/HUST
Unit Testing
Kiểm thử đơn vị
• Unit = smallest testable software component
• Objects
• Procedures/Functions
• Reusable components
• Tested in isolation
• Usually done by programmer during development
• A pair tester can help
• Developer guide or coding guideline can require
• Also known as component or module testing
8/18/25 IT4501 - Software Engineering Department - 7
SoICT/HUST
Dynamic Unit Test Environment
• An environment for dynamic unit testing is created by emulating the
context of the unit under test
• The context consists of:
• A caller of the unit
• All the other units called by the unit
8/18/25 IT4501 - Software Engineering Department - SoICT/HUST 8
Test Driver
• The caller unit is called test driver
• A program that invokes the unit under test
• The unit under test executes with input values received from the
driver and return a value to the driver
• The driver compares the actual outcome with the expected
outcome and reports the ensuing test result
8/18/25 IT4501 - Software Engineering Department - 9
SoICT/HUST
Stubs
• The units called by the unit under test are called stubs
• A stub is a dummy subprogram that replaces a unit that is called by
the unit under test
• A stub performs two tasks:
• It shows an evidence that the stub was called
• It returns a precomputed value to the caller so that the unit under
test can continue its execution
8/18/25 IT4501 - Software Engineering Department - 10
SoICT/HUST
Integration Testing
Kiểm thử tích hợp
• At the unit testing level, the system exists in pieces under the control
of the programmers
• Put the modules together to construct the complete system
• The path from tested components to constructing a deliverable system
contains two major testing phases:
• Integration testing
• System testing
8/18/25 IT4501 - Software Engineering Department - 11
SoICT/HUST
Motivation of Integration Testing
• Different
Motivation modules created by groups of different 7
are generallyTesting
of Integration
developers
• Interface errors between modules created by different programmers
and even by
• Different the same
modules programmers
are generally created byare rampant
groups of different
developers
• Unit testing of individual modules is carried out in a controlled environ-
• Interface errors between modules created by different programmers and
ment by using test drivers and stubs. It is therefore difficult to predict
even by the same programmers are rampant
the behavior of a module in its actual environment after the unit
• Unit testing
testing of individual modules is carried out in a controlled environ-
is performed
ment by using test drivers and stubs. It is therefore difficult to predict the
• Some modules
behavior are more
of a module errorenvironment
in its actual prone than other
after modules,
the unit testing isbecause of
their inherent complexity. It is essential to identify the ones causing
performed
most
• Some failures.
modules are more error prone than other modules, because of
their inherent complexity. It is essential to identify the ones causing most
failures.
8/18/25
IT4501 - Software Engineering Department - SoICT/HUST IT4501 - Software Engineering Department - 12/20/18 12
SoICT/HUST
Objectives of Integration Testing
• To build a WORKING version of the system by putting the modules
together
• To ensure that additional modules work as expected without disturbing
the functionalities of the modules already put together
• Integration test is completed when the system is fully integrated
together:
• All the test cases have been executed
• All the severe and moderate defects found have been fixed and the system is
retested
8/18/25 IT4501 - Software Engineering Department - 13
SoICT/HUST
Interfaces between modules
• Modules are interfaced with other modules to relize the system’s
functional requirements
• An interface between two modules allows one module to access the
service provided by the other
• An interface between two modules implements a mechanism for
passing control and data between modules C1 C2
8/18/25 IT4501 - Software Engineering Department - 14
SoICT/HUST
Different types of Interfaces between modules
Three common paradigms for interfacing modules
• Procedure Call Interface: a procedure in one module call a procedure
in another module. The caller passes on control and data to the called
module. The called one can pass data to the caller while returning
control back to the caller
• Shared Memory Interface: A block of memory is shared between two
modules. Data are written into the memory block by one module and
are read from the block by the other
• Message Passing Interface: One module prepares a message by
intializing the fields of a data structure and sending the message to
another module. This form is common in client-server or web-based
system
8/18/25 IT4501 - Software Engineering Department - 15
SoICT/HUST
Interface Errors
If all the unit tested modules work individually, why can these
modules not work when put together?
8/18/25 IT4501 - Software Engineering Department - 16
SoICT/HUST
Interface Errors
• Construction: interface specification is separated from the
implementation code (i.e., in C/C++ through #include header.h).
Inappropriate use of #include statements cause construction errors
• Inadequate Functionality: Implicit assumptions in one part of a system
that another part of the system would perform a function
• Location of Functionality: Disagreement on or misunderstanding about
the location of a functional capability within the software leads to this
sort of error
• Changes in Functionality: Changing one module without correactly
adjusting for that change in other related modules affects the
functionality of the program
8/18/25 IT4501 - Software Engineering Department - 17
SoICT/HUST
Interface Errors (cont.)
• Added Functionality: A completely new functional module was added
as a system modification
• Misuse of Interface: one module makes an error in using the interface
of a called module. Interface misuse can take the form of wrong
parameter type, wrong parameter order or wrong number of
parameters passed
• Misunderstanding of Interface: A calling module may misunderstand
the interface specification of a called module. The called module may
assume that some parameters passed to it satisfy a certain condition
whereas the caller does not ensure that the condition holds.
• ...
8/18/25 IT4501 - Software Engineering Department - 18
SoICT/HUST
Advantages of Integration Testing
• Defects are detected early
• It is easier to fix defects detected early
• Get earlier feedback on the health and acceptability of the individual
modules and on the overall system
• Scheduling of defect fixes is flexible and it can overlap with
development
8/18/25 IT4501 - Software Engineering Department - 19
SoICT/HUST
Who do integration testing?
• System integration testing is performed by the system integration
group, aka a build engineering group
• Integration test engineers who should be familiar with the interface
mechanisms
• Team of engineers who built the modules
• The system architects because of the fact that they have a bigger
picture of the system
8/18/25 IT4501 - Software Engineering Department - 20
SoICT/HUST
Granularity of System Integration Testing
• System integration testing is performed at different levels of
granularity
• Use both of two techniques
• Black box testing
• White box testing
• Different levels:
• Intrasystem Testing
• Intersystem Testing
• Pairwise Testing
8/18/25 IT4501 - Software Engineering Department - 21
SoICT/HUST
Intrasystem Testing
• Low-level integration testing with the objective of combining the
modules together to build a cohesive system
• Combining modules progresses in an incremental manner
• Example: in a client-server system, individual modules of client and
server are combined in an incremental fashion, to be tested
• Source of testing: low-level design document which details the
specification of modules
8/18/25 IT4501 - Software Engineering Department - 22
SoICT/HUST
Intersystem Testing
• A high-level testing phase which requires interfacing independently
tested systems
• All systems are connected together
• Testing is conducted from end to end: ensuring that the interaction
between systems work together but not to conduct a comprehensive
test
• Only one feature is tested at a time and on a limited basis
• Test cases are derived from the high-level design document, which
details the overall system architecture
• Ex: integrating client and server to test after perform individually
tested system (client and server)
8/18/25 IT4501 - Software Engineering Department - 23
SoICT/HUST
Pairwise Testing
• There can be many intermediate levels of system integration testing
between intrasystem testing and intersystem testing
• Pairwise testing is a kind of intermediate level of integration testing
• Only two interconnected systems in an overall system are tested at a
time
• The purpose is to ensure that two systems under consideration can
function together
• All other systems are assumed to behave as expected
8/18/25 IT4501 - Software Engineering Department - 24
SoICT/HUST
System Integration Testing Techniques
Các kĩ thuật kiểm thử tích hợp hệ thống
• Incremental
• Top-down
• Bottom-up
• Sandwich
• Big bang
8/18/25 IT4501 - Software Engineering Department - 25
SoICT/HUST
Incremental technique
• Integration testing is conducted in an incremental manner as a series of
test cycles
• In each test cycle: a few more modules are integrated with an existing
and tested build to generate a larger build
• Objective:
• Complete one cycle of testing
• Fix all the errors found
• Continue the next cycle of testing
• Finish building a complete and ready system for system testing
8/18/25 IT4501 - Software Engineering Department - 26
SoICT/HUST
How many test cycles for system integration testing?
The number of system integration test cycles and the total integration
time depend on:
• Number of modules in the system
• Relative complexity of the modules (McCabe Cyclomatic Complexity)
• Relative complexity of the interfaces between modules
• Number of modules needed to be clustered together in each test cycle
• Whether the modules to be integrated have been adequately tested before
• Turnaround time for each test-debug-fix cycle
8/18/25 IT4501 - Software Engineering Department - 27
SoICT/HUST
Constructing a build in each test cycle
• Constructing a build is a process by which individual modules are
integrated to form an interim software image
• A software image is a compiled software binary
• The final build will be a candidate for system testing
• Creating a daily build is very popular to facilitate a faster delivery of
the system
• Focusing on small incremental testing, steadily increasing the number
of test cases and regression testing from build to build
8/18/25 IT4501 - Software Engineering Department - 28
SoICT/HUST
Software Quality Assurance and Testing
(end of lecture)
29