Beating the Systematic Software Testing in a Non Systematic way
Many a times systematic testing of the software product becomes insufficient and frustrating for the software testing engineers! Reasons being the defects are truly cunning & call for attacking them in equally unpredictable ways.
Here comes the deployment of non-systematic testing techniques as an effective substitute for the systematic testing techniques.
I am discussing two non-systematic techniques that are:
2) Error guessing
It is a type of security testing, meant for testing how resistant a software product is to the people intending to break into it in different ways & for different reasons, may be like incidental mistakes, form fun sake or due to criminal intentions.
The need for secure systems is growing day by day, so is the requirement of powerful and sophisticated security testing. One of the reasons of this is exponential growth of e-commerce & e-business market & at the same time development of more and more applications aimed to get Web access for something or the other.
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 Interface)
# 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 interfaces.
A) User interface related attacks:
# 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 input buffers
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 & files
# Executing the transactions or programs
# Illegally gaining control over the user accounts
# Illegally gaining control over the privilege management system
# Illegally gaining control over network management system
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 of checklists.
The coverage for error-guessing testing is related to the software testing engineer�s experience, which is generally not easily documented.