Active Topics Memberlist Calendar Search Help | |
Register Login |
One Stop Testing Forum : Types Of Software Testing @ OneStopTesting : Manual Testing @ OneStopTesting |
Topic: Testing? What testing? |
|
Author | Message |
Anil
Newbie Joined: 23Feb2007 Online Status: Offline Posts: 1 |
Topic: Testing? What testing? 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 Post Resume: Click here to Upload your Resume & Apply for Jobs |
|
IP Logged | |
Forum Jump |
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |
© Vyom Technosoft Pvt. Ltd. All Rights Reserved.