checklists of attacks are quite useful to
analysts defining requirements & to the software Testing engineers.
Every software product is vulnerable for intrusions especially at interfaces.
The product interfaces that can be vulnerable are:
# Operating system
# API (Application Programming
# Data storage like the file system
Intelligent testers use the attacks to find the areas where the product will
be vulnerable to failure may be due to some misuse or faults present in the
A) User interface related
# Use inputs, which would compel popping up of
the maximum number of error messages
# Use inputs, which would compel the
software application to go back to the default values
# Explore permissible
data types & character sets
# Use inputs, which would compel overflow of
B) Stored data attacks:
Use inputs with the help of several initial conditions
# Compel the data
structure to store too less or too high values
# Try to find out different
methods to change the internal data constraints
C) Media based attacks:
Overload the file system to its full capacity
# Compel the media to be either
busy or not available
# Try to spoil the media
D) Many more methods by which testers can attack
the software application is by:
# Illegally gaining control over the resources like restricted data &
# Executing the transactions or programs
# Illegally gaining
control over the user accounts
# Illegally gaining control over the privilege
# Illegally gaining control over network management
The advantage of using attack-driven testing is that security holes can be
closed before attackers find them. A pitfall is that this may create a false
sense of security. There is no end to the imagination of those who want to do
wrong, and we have to stay constantly alert to new weak spots. This is why
checklists of any kind must be kept up-to-date with new experiences.
2) Error Guessing:
It is a specialized testing technique utilizing the past experience of the
software testing engineer to visualize the types of faults that could be there
in the test object due the developmental errors, and to create specialized tests
just to dig them out
It means that the software testing engineer primarily banks upon
his past experience acquired out of execution of structured tests or may be out
of other test assignments to judge the place of faults in the test object.
The software testing engineer has to use his creativity by thinking out of
the box, looking around every nook & corner of the application - both in
relation to how the structured tests have been structured, how the test object
has been produced, and the nature of the faults already found.
In relation to the testing approach the software testing engineers can try to
find alternative approaches, and ask himself:
# How it could be done in a different way?
# What would it be completely unlikely to do?
# What assumptions may the software testing engineers, who performed the
structured tests, have made?
In relation to how the test object has been produced, software testing
engineers can ask himself:
# What assumptions may the analysts or the programmers have made?
# What happens if I use a value of 0 (both input and output)?
# What about cases of "none" and "one" in lists?
# What happens if I go over the limit?
# Are there any cases of "coincidence," for example, same value twice or same
value for all?
The software testing engineers can exploit the faults already found to
generate new ideas & can for example ask himself:
# Are there other faults like this?
# Are there any reverse faults?
# Are there any perpendicular faults?
All these questions and many more can be created & maintained in the form
The coverage for error-guessing testing is related to the software testing
engineer’s experience, which is generally not easily documented.