SE101 : Introduction to SE

BSSE/BSAI-II-A/B : Spring 2025

Topic: Software Testing

Uswah Ahmad Khan

Lecturer

Slides Credit: Dr. Qurat-ul-Ain

Last Week!
❖ Design Principles

❖ Design Patterns

❖ Software Architecture

2
Software Design and Implementation
❖ Process to convert system specification into an executable
❖ Software design
○ Design a software structure that realizes the specification;
■ Design Principles
■ Design Patterns
■ Software Architecture
❖ Implementation
○ Translate this structure into an executable program;

System Software Executable

Specification Structure System
3
Recap
Meet customer’s
How will it do? changing need

Design &
Specification Validation Evolution
Implementation

What will system Does it do what

do? customers want?

Requirement Engineering Process 4

Verification & Validation
❖ Verification:
"Are we building the product right”.
○ The software should conform to its specification.

❖ Validation:
"Are we building the right product”.
○ The software should do what the user really requires.

5
Verification and Validation: Example
❖ Verification Example: Imagine a team is developing a
new mobile banking app. During the verification phase,
they review the requirements and design documents.
They check if all the specified features like fund transfer,
account balance check, and transaction history are
included and correctly detailed in the design. They also
perform peer reviews and inspections to ensure the
design aligns with the requirements. This step ensures
that the app is being built according to the initial plan
and specifications without actually running the app.

6
Verification and Validation: Example
❖ Validation Example: In the validation phase, the team
starts testing the mobile banking app on actual devices.
They check if users can log in, transfer money, and view
their transaction history as intended. Testers perform
usability tests to ensure the app is user-friendly and
functional tests to ensure all features work correctly.
They might also involve real users to provide feedback on
the app's performance. This phase ensures that the app
works as expected and meets user needs in real-world
scenarios.

7
Software Testing
❖ Testing is intended to show that a program does what it
is intended to do and to discover program defects before it
is put into use.

❖ You check the results of the test run for errors, anomalies
or information about the program’s non-functional
attributes.

Can reveal the presence of errors NOT their absence.

8
Why Testing??
❖ To demonstrate to the developer and the customer that the
software meets its requirements.
○ Validation testing
■ A successful test shows that the system operates as
intended.
❖ To discover situations in which the behavior of the software
is incorrect, undesirable or does not conform to its
specification.
○ Defect testing
■ A successful test is a test that makes the system
perform incorrectly and so exposes a defect in the
system. 9
A model of the software testing process

An input–output model of program testing

10
Approaches of Software Testing

Black Box Testing Grey Box Testing White Box Testing 11

12
Test Case

A test case is a document, which has a set of test data,

preconditions, expected results and postconditions,
developed for a particular test scenario in order to verify
compliance against a specific requirement.

13
Test Case (Template)

14
Test Case (Example)

15
Test Scenario and Test Case
Test Scenarios are one-liner statement
while
Test Cases is positive and negative inputs, navigation steps,
Expected results, pre and post condition, etc.
Test Scenarios are high-level actions.
while
Test Cases are low-level actions.
16
Test Scenario and Use Case
❖ Test Scenarios can be derived usually from Use cases

17
Levels of Software Testing
assess software with
Unit Testing respect to

Software Testing
implementation

assess software with

Module Testing respect to detailed
design

assess software with

Integration Testing respect to subsystem
design

assess software with

System Testing respect to architectural
design

assess software with

Acceptance Testing
respect to requirements
18
Levels of Software Testing (based on Software
Activity)
Unit Testing Implementation

Software Testing Module Testing Detailed Design

Integration Subsystem
Testing Design
Architectural
System Testing
Design
Acceptance Requirement
Testing Analysis 19
Levels of Software Testing (based on Software
Activity)
Unit Testing Implementation

Software Testing Module Testing Detailed Design

Integration Subsystem
Testing Design
Architectural
System Testing
Design
Acceptance Requirement
Testing Analysis 20
Levels of Software Testing (based on Software
Activity)
Unit Testing Implementation

Software Testing Module Testing Detailed Design

Integration Subsystem
Testing Design
Architectural
System Testing
Design
Acceptance Requirement
Testing Analysis 21
Levels of Software Testing (based on Software
Activity)
Unit Testing Implementation

Software Testing Module Testing Detailed Design

Integration Subsystem
Testing Design
Architectural
System Testing
Design
Acceptance Requirement
Testing Analysis 22
Levels of Software Testing (based on Software
Activity)
Unit Testing Implementation

Software Testing Module Testing Detailed Design

Integration Subsystem
Testing Design
Architectural
System Testing
Design
Acceptance Requirement
Testing Analysis 23
Stages of testing
❖ Development testing,
○ where the system is tested during development to
discover bugs and defects.
❖ Release testing,
○ where a separate testing team test a complete version
of the system before it is released to users.
❖ User testing,
○ where users or potential users of a system test the
system in their own environment.

24
Development Testing
1. Unit testing,
■ where individual program units or object classes are tested.
■ Unit testing should focus on testing the functionality of objects
or methods.
2. Component testing,
■ where several individual units are integrated to create
composite components.
■ Component testing should focus on testing component
interfaces.
3. System testing,
■ where some or all of the components in a system are integrated
and the system is tested as a whole. 25
Unit Testing
❖ Unit testing is the process of testing individual
components in isolation.
❖ It is a defect testing process.
❖ Units 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.

26
 assertEqual() – This
statement is used to
check if the result
obtained is equal to
the expected result.

https://www.geeksforgeeks.org/unit-testing-python-unittest/
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.

28
assertTrue() / assertFalse()
– This statement is used to
verify if a given statement is
true or false.
The 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
sequences to cause these transitions
❖ For example:
○ Shutdown -> Running-> Shutdown
○ Configuring-> Running-> Testing ->
Transmitting -> Running
○ Running-> Collecting-> Running->
Summarizing -> Transmitting -> Running
30
Weather station state diagram
Automated testing
❖ Whenever possible, unit testing should be automated so
that tests are run and checked without manual
intervention.
❖ In automated unit testing, you make use of a test
automation framework (such as JUnit) to write and run
your program tests.
❖ Unit testing frameworks provide generic test classes that
you extend to create specific test cases. They can then run
all of the tests that you have implemented and report,
often through some GUI, on the success of otherwise of
the tests.
33
Automated test components
❖ A setup part, where you initialize the system with the
test case, namely the inputs and expected outputs.

❖ A call part, where you call the object or method to be

tested.

❖ An assertion part where you compare the result of the

call with the expected result. If the assertion evaluates to
true, the test has been successful if false, then it has
failed.
34
Unit test effectiveness
❖ The test cases should show that, when used as expected, the
component that you are testing does what it is supposed to do.
❖ If there are defects in the component, these should be
revealed by test cases.
❖ This leads to 2 types of unit test case:
○ The first of these should reflect normal operation of a
program and should show that the component works as
expected.
○ The other kind of test case should be based on testing
experience of where common problems arise. It should use
abnormal inputs to check that these are properly
processed and do not crash the component. 35
Testing strategies
❖ Partition testing, where you identify groups of inputs that
have common characteristics and should be processed in
the same way.
○ You should choose tests from within each of these
groups.
❖ Guideline-based testing, where you use testing guidelines
to choose test cases.
○ These guidelines reflect previous experience of the
kinds of errors that programmers often make when
developing components.
36
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.

37
Equivalence Partition

❖ Two invalid classes will be:

a) Less than or equal to 17.

b) Greater than or equal to 61.

❖ A valid class will be anything between 18 and 60.

38
Boundary Value Analysis

39