Chapter 7
Application
Software Testing
7.1
Introduction
Testing
of an Application Software product plays a major role in it’s
development process, as it is vital to ensure products quality and
reliability. I was able to grasp these concepts and practical
experience when I worked in QuickAccountant.com Beta
release Testing.
Testing
of Application Software fall into two broad categories.
1.
Glass box testing (White box testing)
2.
Black box testing
7.2 Glass Box Testing
Usually
glass box testing is done by
1.
Programmers after coding
2.
Testers
Following
tests are performed and all problems must be fixed in this stage
to verify that the program is ready for black-box testing.
Tests performed during glass-box
testing
Path
Testing
Path
testing is done to make sure the program flow is in the correct
way as expected. Basic paths, loops, and conditions are checked in
this stage. Coverage Criteria for path testing is specified in the
document Glass-box
testing checklist.
It
can consist of following:-
Branch
testing –Checks all
lines and the branch points once when the condition is true and once
when it’s false.
Condition
testing–Same as above but tests all the ways that a certain
condition can be made
true or false.
Static
Testing
Static Testing is done only by examining the code.
This covers examining
1.
The basic structure of the program
2.
Checks whether proper naming conventions are followed and
code is readable.
3.
Checks whether programs are properly commented and version
numbers and other information are correct.
4.
Checks for redundant code.
Loop Testing
Loop
Testing is a Glass-Box Testing technique that focuses exclusively
on the validity of loop constructs. Four different classes of
loops can be defined as simple loops, concatenated loops, nested
loops and unstructured loops.
Simple
Loops
Following set of tests should be applied to simple loops,
where ‘n’ is the maximum number of allowable passes through
the loop.
1.
Skip the loop entirely
2.
Only one pass through the loop
3.
Two passes through the loop
4.
m passes through the loop
5.
n-1,n,n+1 passes through the loop
Nested
Loops
When extending the test approach for simple loops to nested
loops, the number of possible tests would grow geometrically as
the level of nesting increases. As this would result an
impractical number of tests, following approach must be followed
to reduce the number of tests.
1.
Start the innermost loop. Set all the other loops to
minimum values.
2.
Conduct simple loop tests for the innermost loop while
holding the outer
loops at their minimum iteration parameter(e.g. loop counter)
values. Add other tests for out-of-range or excluded values.
3.
Work outward, conducting tests for the next loop, but
keeping all other outer loops at minimum values and other nested
loops to “typical” values.
4.
Continue until all loops have been tested.
Concatenated
Loops
Concatenated loops can be tested using the approach defined
above for simple loops of each of the loops are independent of the
other. However if the loops are concatenated and the loop counter
for loop 1 is used as the initial value for loop2, then the loops
are not independent. When the loops are not independent, the
approach applied to nested loops is recommended.
Unstructured Loops
Loops
that do not fall into above categories are known as unstructured
loops and these loops must be avoided. These loops must be
redesigned, following structured programming methods.
Fig
7.1 Glass Box Testing
7.3 Black Box Testing
Black-Box
Testing is done by testers, after Glass-Box Testing. In this
stage, program is tested mainly from outside without the
source-code.
Following
methods are used for Black-Box testing.
1.
Incremental Testing
2.
Big-Bang Testing
In
this strategy each module, element or function is tested
thoroughly but separately. After those tests were successful few
were grouped together and tested and eventually all the functions
and modules are tested together.
Incremental
testing requires Stubs (code or a program written to take a
functions place) and Drivers (code or program written to call a
function and pass it data), as some functions or modules cannot be
tested individually.
Incremental
testing can be done in two ways when the product has been designed
hierarchically.
1.Bottom-Up Testing
Lowest
level modules are tested first. Then highest level modules are
tested and tested lower level modules will be also used. Requires
Drivers. This is the recommended method.
2. Top - Down Testing
Highest
level modules are tested first. Then Next higher level modules are
tested. Requires Stubs.
This
type of testing is done mainly for time saving purposes In this
type of testing drivers and stubs (test code) are not required as
modules and processes are not thoroughly tested until the full
system is developed. This
method must be only used for immediate projects with strict
deadlines.
The
normal sequence is as following
1.
Test Planning.
2.
Function test, System test, verification and validation
(Test Cycle Design and Execution)
3.
Integrity and release testing (Test Cycle Design and
Execution)
4.
Final acceptance testing and certification
Fig
7.2 Black Box Testing
7.4
Test cases and test case designing
Following
Documents are prepared/submitted by the design team and
programmers.
1.
Design Specification
2.
System Specification
3.
Module Specification
4.
Function List
5.
Program/Function Path List
6.
Software Requirement Specification
7.
Module Inter-Dependency Chart
Evolutionary
method where testing is done right after the development of a
certain function or a unit is used for test planning and testing
should be done in Incremental method unless for special cases
where you really need Big-Bang testing. (specially for time
saving).
The
following documents are also prepared and used for effective test
planning.
·
List of error messages
·
List of program files
·
List of compatible Hardware/Software/compatible
environments
·
List of components that goes to the customer
·
List of public documents (list of every document from
anyone outside the company)
Test
Plan Report is
prepared at this stage.
7.5 Testing User Manuals & online help
User
Manuals and Online Help must be tested at the Final Integrity
Testing level.
Testing
User Manuals/Documentation
Good
Documentation of a Software Product serves following benefits,
- Improves
usability – Documentation must make the product easier to
use. This leads to faster learning and fewer errors.
- Lowers
customer costs – Good documentation prevents many
unnecessary support calls from the customer.
- Improves
reliability – Excellent documentation helps to reduce the
number of user errors.
- Increase
maintainability
- Improves
installability
- Enhances
salability
Chapter
8 >>
|
