Print Page | Close Window

Testing? What testing?

Printed From: One Stop Testing
Category: Types Of Software Testing @ OneStopTesting
Forum Name: Manual Testing @ OneStopTesting
Forum Discription: Discuss All that is need to be known about Manual Software Testing and its Tools.
URL: http://forum.onestoptesting.com/forum_posts.asp?TID=208
Printed Date: 28Dec2024 at 9:47pm


Topic: Testing? What testing?
Posted By: Anil
Subject: Testing? What testing?
Date Posted: 23Feb2007 at 12:23pm
What is a test?
The core thesis of this paper is the idea1 that a test
consists of three things: a system in a defined
state, a defined transaction, and a confirmation
that the system arrives in a defined state.
initial
state transaction
destination
state
This is an overly simplistic statement, but remains
remarkable useful. The "system" under test could
be a simple object, a collection of interrelated
objects, a whole application, or a distributed
multi-layer client-server system. Equally, the
initial
state
destination
state
oops
Please note that this is a simplistic definition of a
test. It does not cover all forms of testing (such as
tests of usability, maintainability, portability,
robustness and so on which make up the other
zillion software sub-characteristics listed in ISO
9126) and it is no substitute for a well thought out
test plan. It does, however, provide some
language for talking about functional testing.
transaction could be a single byte of input, a
single edge of a state transition diagram, or a
series of transactions lumped together as a single
event being considered.
Confirming that the system under test has arrived
in a particular state can be done in may ways.
Some states are clearly visable, sometimes they
are available but not useful, and some internal
states are not for user consumption and are much
harder to access and therefore harder to confirm.
2. Manual testing is no testing
Humans are really bad at boring, repetitive tasks.
If your test plan is based on the idea that your
staff will faithfully execute a long list of printed
instructions, at least once per release, then your
testing is probably not effective.
1. There is a growing body of knowledge called
"Transaction Based testing" or sometimes "Transaction
Based Verification".
For example, many manual test plans contain long
sequences of things the operator is required to do,
often with information on the screen to be
confirmed as correct. This is all very well for
successful tests, but what happens when one fails?
Usually, these test scripts cover large numbers of
behaviors. There is thus a motivation to complete
the rest of the script, rather than stop, and have to
Testing? Whattesting? PeterMiller Page 1



Print Page | Close Window