Getting a bit more specific I figured I’d post something
that my team created as a helpful resource for people building test plans.
This document started as a one page guide, and turned into a five page list of interesting
tests as it passed from tester to tester in the developer division. Please don’t
consider this a comprehensive list and assume we covered everything. It was
and is only meant as a starting point to help get the creative juices flowing around
building your test plan. The more people that see it the more good examples
we’ve added so feel free to contribute to any gaping holes in this guide!
The guide is broken out by the different resource types
that a program might depend on.
to get a list of all the errors that the code is supposed to handle and try causing
all of them at least once.
a. Are the invalid inputs handled
b. Are there any cases that
you think the code should be handling, but you don’t see an associated error message?
c. Are all error messages easy
to understand and descriptive?
using the default values or blank inputs (where applicable)
d. Ask yourself whether the
defaults are reasonable. Is that what the user would want to have as the default value?
strings that have special meaning to the OS, Underlying Programming Language or are
special for the corresponding char set
for buffer overruns.
sure that your feature doesn’t allow code/script to be injected through input. Online
features and features using SQL are especially susceptible to this kind of problems.
repeating the same input or series of inputs many times.
test input only as individual fields, find related inputs and test interesting combinations.
For example if you had month and date fields, test February and -1, 0, 28, 29.
about all the possible outputs that some input can result in. Try to cause all of
those to happen, by changing the context/environment in which the code executes. For
example, when trying to read a file from disc some possible outputs are:
e. File is not found
f. We could not read the file - File is corrupted so
we can’t read it, No permissions to read the file, File is locked so can’t read
g. Successfully read the file
h. The program hung because
the file was too big
Common Data Type - Boundary Values
0 to 65,535
0 to 4,294,967,295
-32,768 to 32,767
-2,147,483,648 to 2,147,483,647
256 different values
65,535 different values
True or False
1.2e-38 to 3.4e38
2.2e-308 to 1.8e308
3.4e-4932 to 1.1e4932
REFERENCES / RESOURCES:
To Break Software
Heat – http://se.fit.edu/cannedheat