Software in Many Dimensions
Software in Many Dimensions
It is useful to think of software as a multi-dimensional entity
with many different axes. For example one axis is the code of
the program, which will be broken down into modules and
units. Another axis will be the input data and all the possible
combinations. Still a third axis might be the hardware that the
system can run on, or the other software the system will
interface with.
Testing can then be seen as an attempt to achieve "coverage"
of as many of these axes as possible .
Remember we are no longer seeking the impossible 100%
coverage but merely 'best' coverage, verifying the function of all the areas of risk.
Outlining
To start the process of test planning a simple process of `outlining' can be used :
1. List all of the 'axes' or areas of the software on a piece of paper (a list of possible areas can
be found below, but there are certainly more than this).
2. Take each axis and break it down into its component elements.
For example, with the axis of "code complexity" you would break the program down into
the `physical' component parts of code that make it up. Taking the axis of "hardware
environment" (or platform) it would be broken down into all possible hardware and
software combinations that the product will be expected to run on.
3. Repeat the process until you are confident you have covered as much of each axis as you
possibly can (you can always add more later).
This is a process of deconstructing the software into constituent parts based on different
taxonomies. For each axis simply list all of the possible combinations you can think of. Your testing
will seek to cover as many elements as possible on as many axes as possible.
The most common starting point for test planning is functional decomposition based on a
technical specification. This is an excellent starting point but should not be the sole 'axis' which is
addressed otherwise testing will be limited to 'verification' but not 'validation'.
Axis / Category
Explanation
Functionality
As derived from the technical specification
Code Structure
The organisation and break down of the source or object code
User interface elements
User interface controls and elements of the program
Internal interfaces
Interface between modules of code (traditionally high risk)
External interfaces
Interfaces between this program and other programs
Input space
All possible inputs
Output space
All possible outputs
Physical components
Physical organisation of software (media, manuals, etc.)
Data
Data storage and elements
Platform and environment
Operating system, hardware platform
Configuration elements
Any modifiable configuration elements and their values
Use case scenarios
Each use case scenario should be considered as an element
21
Figure 7 : Software dimensions
