Software Testing
ISYS3416/32 Software Engineering Fundamentals for IT
Module Learning Outcome
• MLO1: Explain the principles, models, and processes of
software testing, including its purpose within the software
development lifecycle.
• MLO2: Differentiate between mistake, fault, error, and failure,
and relate these concepts to software quality assurance.
• MLO3: Apply and evaluate various testing types and
acceptance testing to ensure that software meets
requirements and functions as intended.
Why Do We Test Software?
A tester’s goal is to eliminate faults as early as possible
• Improve quality
• Reduce cost
• Preserve customer satisfaction
Testing
• Testing is the most time-consuming and expensive part of
software development
• No testing is even more expensive
• If we have too little testing effort early, the cost of testing
increases
• Planning for testing after development is prohibitively
expensive
Poor Program Manager might say:
“Testing is too expensive.”
Cost of Late Testing
Software Faults, Errors & Failures
• Software Error: An incorrect internal state that is the manifestation of
some fault.
• Human Mistake, it happens during development
• Software Fault: A static defect in the software
• Defect in code/design is happen when introduced into the software.
• Software Failure: External, incorrect behavior with respect to the
requirements or other description of the expected behavior
• Incorrect behavior is happen when the software runs
Faults in software are equivalent to design mistakes in
hardware.
Fault, Failure and Error Example
• A patient gives a doctor a list of symptoms
• Failures
• The doctor tries to diagnose the root cause, of the disease
• Fault
• The doctor may look for anomalous/ malfunctioning internal conditions (high blood pressure,
irregular heartbeat, bacteria in the bloodstream)
• Errors
A Concrete Example
8
The Term BUG
Bug is used informally
Sometimes speakers mean fault, sometimes error, sometimes
failure… often the speaker doesn’t know what it means!
9
Validation & Verification (IEEE)
• Verification: The process of determining whether the products
of a given phase of the software development process fulfill
the requirements established during the previous phase
• Validation: The process of evaluating software at the end of
software development to ensure compliance with intended
usage
10
Difference between Verification &
Validation
Verification Validation
Are you building it right? Are you building the right thing?
The verifying process includes checking It is a dynamic mechanism of testing and
documents, design, code, and program validating the actual product
Whether the software conforms to It checks whether the software meets the
specifications is checked requirements and expectations of a
customer
It finds bugs early in the development cycle It can find bugs that the verification process
cannot catch
Target is an application and software Target is an actual product
architecture, specification, complete design,
high-level, and database design, etc.
QA team does verification and make sure With the involvement of testing team
that the software is as per the requirement in validation is executed on software code
the SRS document
It comes before validation It comes after verification
11
Testing Level
Unit Testing (White Box)
• The most ‘micro’ scale of testing.
• Tests done on particular functions
• Requires knowledge of the internal
program design and code.
• Done by Programmers (not by
testers).
• Disadvantage: the tester may be
biased by previous experience. And
the test value may not cover all
possible values.
Module Testing (Black Box)
• Designed to exercise to its external
specifications
• Testers are not biased by
knowledge of the program’s design.
• Disadvantages:
• The need for explicitly stated
requirements
• Only cover a small portion of the
possible test conditions.
Integration Testing
• Testing of combined parts of an application to determine their
functional correctness.
• ‘Parts’ can be
• Code modules
• Individual applications
• Client/server applications on a network.
Integration Testing
• Bottom-up integration testing begins with unit testing,
followed by tests of progressively higher-level combinations of
units called modules or builds.
• Top-Down integration testing, the highest-level modules are
tested first and progressively lower-level modules are tested
after that. In a comprehensive software development
environment, bottom-up testing is usually done first, followed
by top-down testing.
Integration Testing
• Sandwich
• Test units in layers
• Test middle layer via higher and lower layer
• Big bang
• System tested as a whole
• Not good for large systems
• Hard to isolate the fault location
Integration Testing
• Incremental Integration – in which individual modules are
integrated and tested step-by-step, one at a time or in small
groups, to ensure proper interaction and functionality between
them
• Continuous Integration is an automated software testing
process where code changes are automatically built,
integrated, and tested every time a developer commits
changes to a shared repository.
System Testing
Objectives • To verify that the system components perform control functions
• To perform inter-system test
• To demonstrate that the system performs both functionally and
operationally as specified
• To perform appropriate types of tests relating to Transaction Flow,
Installation, Reliability, Regression etc.
When • After Integration Testing
Input • Detailed Requirements & External Application Design
• Master Test Plan
• System Test Plan
Output • System Test Report
Acceptance Testing
Objectives • To verify that the system meets the user requirements
When • After System Testing
Input • Business Needs & Detailed Requirements
• Master Test Plan
• User Acceptance Test Plan
Output • User Acceptance Test Report
Acceptance Test: Include Alpha and Beta Testing
Model of the software testing process
22
Example of Test Cases
Test Test Test Expected Test Outcome
Scenario Cases Data Result Result (Pass/Fail)
Example of Test Cases (unit testing)
Test Scenario Test Cases Test Data Expected Test Result Outcome
Result (Pass/Fail)
Check the Test Case 1: Password: Password is Password is PASS
functionality of Verify the ABCD1234 Invalid Invalid
the Password function with
checking an
function INCORRECT
password
Test Case 2: Password: Password is Password is FAIL
Verify the ABCD1234@ Valid Invalid
function with
CORRECT
password
Object class testing
• Complete test coverage of a class involves
• Testing all operations associated with an object
• Testing all object attributes
• Exercising the object in all possible states.
25
Example: The weather station object
interface
26
Weather station testing
The class has a single attribute, which is its identifier. This is a
constant that is set when the weather station is installed. You
therefore only need a test that checks if it has been properly set up.
You need to define test cases for all of the methods associated with
the object such as reportWeather and reportStatus.
Thank you!
Any Question?