Software Testing Strategies

By LECTURER TAHIR MAQSOOD

1
 Strategic Approach to Testing - 1
Firstly arrange the components and perform
integration of the entire computer-based
system.
Use different techniques for different
testing's.
The developer of the software conducts
testing and may be assisted by
independent test groups for large projects.
The role of the independent tester is to
remove the conflict of interest , when the
builder is testing his or her own product.
2
 Strategic Approach to Testing - 2
Testing and debugging are different
activities.
Debugging must be accommodated in any
testing strategy.
Need to consider verification issues
 are we making right product at right time?
 Need to Consider validation issues
are we building the right product according
to the user assessment?

3
 Strategic Testing Issues - 3
Specify product requirements must be fulfill
in appropriate manner before testing starts.
Specify testing objectives explicitly.
Identify the user classes of the software
and develop a profile for each.
Develop a test plan that emphasizes rapid
cycle testing.

4
 Strategic Testing Issues - 4
Build robust software that is designed to
test itself (e.g. use anti-bugging).
Use effective formal reviews as a filter prior
to testing.
Conduct formal technical reviews to assess
the test strategy and test cases.

5
 Stages of Testing
Module or unit testing.
Integration testing,
Function testing.
Performance testing.
Acceptance testing.
Installation testing.

6
 Unit Testing
Program reviews.
Formal verification.
Testing the program itself.
black box and white box testing.

7
 Black Box or White Box?
Maximum # of logic paths - determine if
white box testing is possible.
Nature of input data.
Amount of computation involved.
Complexity of algorithms.

8
 Testing Application Controls
Black Box Approach - understanding
flowcharts, input procedures, & output results
White Box Approach - understanding the
internal logic of the application
authenticity (access) tests
accuracy tests
completeness tests
redundancy tests
audit trail tests
rounding error tests
 Unit Testing Details
Interfaces tested for proper information
flow.
Local data are examined to ensure that
integrity is maintained.
Boundary conditions are tested.
Basis path testing should be used.
All error handling paths should be tested.

10
 Generating Test Data

Ideally want to test valid and invalid inputs

Equivalence partitioning it often required to
reduce to infinite test case sets
Every possible input mentioned in parent and
sub- classes
Each point is representative of class.

11
 Regression Testing
Check for defects propagated to other
modules by changes made to existing
program
Representative sample of existing test cases
is used to exercise all software functions.
Additional test cases focusing software
functions likely to be affected by the change.
Tests cases that focus on the changed
software components.

12
 Integration Testing
Bottom - up testing
Top - down testing.
Modified top - down testing - test levels
independently.
Big Bang.
Sandwich testing.

13
 Top-Down Integration Testing

 Main program used as a test driver and stubs

are substitutes for components directly
subordinate to it.
 Subordinate stubs are replaced one at a time
with real components (following the depth-first
or breadth-first approach).
 Tests are conducted as each component is
integrated.
 On completion of each set of tests and other
stub is replaced with a real component.
 Regression testing may be used to ensure that
new errors not introduced.
14
 Bottom-Up Integration
Testing
Low level components are combined in
clusters that perform a specific software
function.
A driver (control program) is written to
coordinate test case input and output.
The cluster is tested.
Drivers are removed and clusters are
combined moving upward in the
program structure.

15
 Validation Testing
Ensure that each function or
performance characteristic conforms to
its specification.
Deviations (deficiencies) must be
negotiated with the customer to
establish a means for resolving the
errors.
Configuration review or audit is used to
ensure that all elements of the software
configuration have been properly
developed, cataloged, and documented
to allow its support during its
16
maintenance phase.
 Acceptance Testing
Approaches
Benchmark test.
Pilot testing.
Parallel testing.

17
 System Testing
Recovery testing
checks system’s ability to recover from
failures
Security testing
verifies that system protection mechanism
prevents improper penetration or data
alteration
Stress testing
program is checked to see how well it deals
with abnormal resource demands
Performance testing
tests the run-time performance of software
18
 Debugging

Debugging (removal of a defect) occurs as

a consequence of successful testing.
Some people better at debugging than
others.
Is the cause of the bug reproduced in
another part of the program?
What “next bug” might be introduced by
the fix that is being proposed?
What could have been done to prevent this
bug in the first place?
19
 Debugging Approaches
Brute force
memory dumps and run-time traces are
examined for clues to error causes
Backtracking
source code is examined by looking
backwards from symptom to potential causes
of errors
Cause elimination
uses binary partitioning to reduce the
number of locations potential where errors
can exist
20
Applications Software

Apply to real-world tasks

Solves user problems

vs. OS
controls the hardware
Acquiring Software
Freeware
Free to all
Copyrighted
Distributed in machine-readable format
Shareware
Freely distributed for a trial period
Pay a nominal fee to register with the author
 Acquiring Software
Public-domain software
Un-copyrighted
May be used or altered without restriction
Generally developed under government grants
Open-source
Free to all
Source code is distributed
May be used or altered
Popular under the LINUX OS
Acquiring Software

Commercial software
Used most often
Copyrighted
Generally costly
May not be copied without permission of the
manufacturer
Purchasing Commercial Software
Individuals
Software warehouse store
Mail order
Electronic software distribution
Purchasing Commercial Software
Businesses
Volume discount
Site license
Network versions
Application Service Provide (ASP)
Software is setup and maintained by ASP
Access the software over the Internet
Pay per use
Saves the expense of installing and maintaining the
software
Software Development Focus

Ease of use
Personal use programs
Personal time organizers
To-do list makers
E-mail programs

Internet access
 Business Software

Custom-written to
meet special business
needs
Standard packages
Combination of
custom-written and
off-the-shelf
Software for Small Business
Keeping Up and Making Contacts
Networking over the Internet

Making Sales Pitches

Graphical presentation software
 Software Piracy
Making illegal copies of copyrighted software
Why the fuss?
Very easy to duplicate software vs. a text book
Software company may lose hundreds of dollars
per pirated copy
Prosecution
Yes: Small-medium sized business who purchase a
few copies and distribute to many users
No: Individual users who probably would not have
purchased software on their own anyway