SOFTWARE TESTING STRATEGIES AND
TECHNIQUES
• Software Testing Strategies
• Software Testing Techniques
Software Testing
Testing is the process of exercising a program
with the specific intent of finding errors prior to
delivery to the end user.
2
What Testing Shows
errors
requirements conformance
performance
an indication
of quality
3
Strategic Approach
• To perform effective testing, you should conduct effective
technical reviews. By doing this, many errors will be
eliminated before testing commences.
• Testing begins at the component level and works
"outward" toward the integration of the entire computer-
based system.
• Different testing techniques are appropriate for different
software engineering approaches and at different points in
time.
• Testing is conducted by the developer of the software and
(for large projects) an independent test group.
• Testing and debugging are different activities, but
debugging must be accommodated in any testing strategy.
4
Black, Gray Box and White Box testing
Black Box Testing Gray Box Testing White Box Testing
This testing has a medium level This testing has high-
1. This testing has Low granularity.
of granularity. level granularity.
It is done by end-users (called
It is done by end-users and also It is generally done by
2. user acceptance testing) and
by the tester and developers. testers and developers.
also by testers and developers.
Here, the Internal code
Here, Internals are not required Here, Internals relevant to the
3. of the application and
to be known. testing are known.
database is known.
It is likely to be less exhaustive Most exhaustive among
4. It is kind of in-between.
than the other two. all three.
It is based on requirements, and It provides better variety/depth
It can exercise code with
test cases on the functional in test cases on account of high-
5. a relevant variety of
specifications, as the internals are level knowledge of the
data.
not known. internals.
Alpha, Beta and Gamma testing
Apha Beta Gamma Testing
Conducted as a final
Conducted externally by
Conducted internally by testers verification before
1. selected end users to evaluate
before release to end users. release without user
real-world usage.
involvement.
End users, customers, or a Internal team, but
2. QA team and internal testers. selected group of external without controlled
users. testing conditions.
Done in a production-
In a controlled lab/test In real-world user
3. like environment with
environment. environments.
minimal monitoring.
Just before the final
Before beta testing, after initial After alpha testing, before the
4. release, as a last
development is complete. final product release.
checkpoint.
Limited to the company’s internal Open or restricted to selected Typically, no external
5.
team. real users. users are involved.
V&V
• Verification refers to the set of tasks that
ensure that software correctly implements a
specific function.
• Validation refers to a different set of tasks that
ensure that the software that has been built is
traceable to customer requirements. Boehm
[Boe81] states this another way:
– Verification: "Are we building the product right?"
– Validation: "Are we building the right product?"
7
Who Tests the Software?
developer independent tester
Understands the system Must learn about the system,
but, will test "gently" but, will attempt to break it
and, is driven by "delivery" and, is driven by quality
8
Testing Strategy
System engineering
Analysis modeling
Design modeling
Code generation Unit test
Integration test
Validation test
System test
9
Testing Strategy
• We begin by ‘testing-in-the-small’ and move
toward ‘testing-in-the-large’
• For conventional software
– The module (component) is our initial focus
– Integration of modules follows
• For OO software
– our focus when “testing in the small” changes from an
individual module (the conventional view) to an OO
class that encompasses attributes and operations and
implies communication and collaboration
10
Strategic Issues
• Specify product requirements in a quantifiable manner long
before testing commences.
• State testing objectives explicitly.
• Understand the users of the software and develop a profile
for each user category.
• Develop a testing plan that emphasizes “rapid cycle testing.”
• Build “robust” software that is designed to test itself
• Use effective technical reviews as a filter prior to testing
• Conduct technical reviews to assess the test strategy and test
cases themselves.
• Develop a continuous improvement approach for the testing
process.
11
Unit Testing
module
to be
tested
results
software
engineer
test cases
12
Unit Testing
module
to be
tested
interface
local data structures
boundary conditions
independent paths
error handling paths
test cases
13
Unit Test Environment
driver
interface
local data structures
Module boundary conditions
independent paths
error handling paths
stub stub
test cases
RESULTS
14
Integration Testing Strategies
Options:
• the “big bang” approach
• an incremental construction strategy
15
Top Down Integration
A
top module is tested with
stubs
B F G
stubs are replaced one at
a time, "depth first"
C
as new modules are integrated,
some subset of tests is re-run
D E
16
Bottom-Up Integration
A
B F G
drivers are replaced one at a
time, "depth first"
C
worker modules are grouped into
builds and integrated
D E
cluster
17
Sandwich Testing
A
Top modules are
tested with stubs
B F G
Worker modules are grouped into
builds and integrated
D E
cluster
18
Regression Testing
• Regression testing is the re-execution of some subset of
tests that have already been conducted to ensure that
changes have not propagated unintended side effects
• Whenever software is corrected, some aspect of the
software configuration (the program, its documentation, or
the data that support it) is changed.
• Regression testing helps to ensure that changes (due to
testing or for other reasons) do not introduce unintended
behavior or additional errors.
• Regression testing may be conducted manually, by re-
executing a subset of all test cases or using automated
capture/playback tools.
19
Smoke Testing
• A common approach for creating “daily builds” for product software
• Smoke testing steps:
– Software components that have been translated into code are integrated
into a “build.”
• A build includes all data files, libraries, reusable modules, and engineered
components that are required to implement one or more product functions.
– A series of tests is designed to expose errors that will keep the build from
properly performing its function.
• The intent should be to uncover “show stopper” errors that have the highest
likelihood of throwing the software project behind schedule.
– The build is integrated with other builds and the entire product (in its
current form) is smoke tested daily.
• The integration approach may be top down or bottom up.
20
General Testing Criteria
Interface integrity – internal and external module interfaces are tested
as each module or cluster is added to the software
Functional validity – test to uncover functional defects in the software
Information content – test for errors in local or global data structures
Performance – verify specified performance bounds are tested
21
Object-Oriented Testing
• begins by evaluating the correctness and
consistency of the analysis and design models
• testing strategy changes
– the concept of the ‘unit’ broadens due to
encapsulation
– integration focuses on classes and their execution
across a ‘thread’ or in the context of a usage scenario
– validation uses conventional black box methods
• test case design draws on conventional methods,
but also encompasses special features
22
High Order Testing
• Validation testing
– Focus is on software requirements
• System testing
– Focus is on system integration
• Alpha/Beta testing
– Focus is on customer usage
• Recovery testing
– forces the software to fail in a variety of ways and verifies that recovery
is properly performed
• Security testing
– verifies that protection mechanisms built into a system will, in fact,
protect it from improper penetration
• Stress testing
– executes a system in a manner that demands resources in abnormal
quantity, frequency, or volume
• Performance Testing
– test the run-time performance of software within the context of an23
integrated system
Swimlane Diagram
How activity diagram helps in Testing
• Online Banking System
If a Swimlane Diagram for a fund transfer process is
created, it would show:
• Customer initiates the transfer → System validates
account details → Bank approves/rejects transaction →
Notification is sent.
• Using this:
✅ Testers can create test cases for valid and invalid
transactions.
✅ Test cases can be written for system failure, timeout,
and notification delays.
THANK YOU !!!