The value of Error Guessing ( EG) lies in the unexpected: tests made up by guessing would otherwise not be considered. Based on the tester's experience, he goes in search of defect-sensitive spots in the system and devises suitable test cases for these.
Experience here is a broad concept: it could be the professional tester who 'smells' the defects in certain complex screen processes, but it could also be the user or administrator who knows the exceptional situations from practice and wishes to test whether the new or amended system is dealing with them adequately.
Together with exploratory testing (See "Exploratory Testing"), error guessing is rather a strange technique among test design techniques. Neither technique is based on any of the described basic techniques and therefore does not provide any specifiable coverage.
This very informal technique leaves the tester free to design the test cases in advance or to create them on the spot during the test execution. Documenting the test cases is optional. A point of focus when they are not documented is the reproducibility of the test. The tester often cannot quite remember under which circumstances a defect occurred. A possible measure for this is the taking of notes (a 'test log') during the test. Obviously, defects found with the test are documented. In those cases, great attention should be paid to the circumstances that have led to the defect, so that it will be reproducible.
An aid for reproducing a defect is the activation of logging during the test, documenting the actions of the tester. A tool for automated test execution can be used for this.
The considerable freedom of the technique makes the area of application very broad. Error guessing can be applied to the testing of every quality characteristic and to every form of test basis.
|Error guessing can also be used, for example, to instil (or restore) users' or administrators' confidence in a system, in the spirit of 'If these situations are processed satisfactorily, then the rest will probably also be all right'.|
In more detail
Error guessing is sometimes confused with exploratory testing (see "Exploratory Testing"). The table below sums up the differences:
In more detail
|In practice, error guessing is often cited for the applied test technique in the absence of a better name – 'It's not a common test design technique, therefore it is error guessing'. In particular, the testing of business processes by users, or the testing of requirements is often referred to as error guessing. However, the basic technique of "checklist" is used here, while with error guessing no specific basic technique is used.|
The fact that tests are executed that otherwise would not be considered makes error guessing a valuable addition to the other test design techniques. However, since error guessing guarantees no coverage whatsoever, it is not a replacement.
By preference error guessing takes place later in the total testing process, when most normal and simple defects have already been removed with the regular techniques. Because of this, error guessing can focus on testing the real exceptions and difficult situations. From within the test strategy, the test manager would normally provide some direction to the aim of error guessing, so that duplication of other tests can be avoided. The test manager also makes a certain amount of time (time box) and resources available.
Points of focus in the steps
The steps can be performed both during the Specification phase and during the test execution. The tester usually does not document the results of the steps, but if great value is attached to showing evidence or transferability and reusability of the test, then this should be done.
1 - Identifying test situations
Prior to test execution, the tester identifies the weak points on which the test should focus. These are often mistakes in the thought processes of others and things that have been forgotten. These aspects form the basis of the test cases to be executed. Examples are:
- Exceptional situations:
- rare situations in the system operation, screen processing or business and other processes
- Fault handling:
- forcing a fault situation during the handling of another fault situation, interrupting a process unexpectedly, etc.
- Non-permitted input:
- negative amounts, zeros, excessive values, too-long names, empty (mandatory) fields, etc. (only useful if there is no syntactic test carried out on this part)
- Specific combinations, for example in the area of:
- Data: an as-yet untried combination of input values
- Sequence of transactions: e.g. "change – cancel change – change again – cancel – etc." a number of times in succession
- Claiming too much of the system resources (memory, disk space, network)
- Complex parts of the system
- Often-changed parts of the system
- Parts (processes/functions) of the system that often contained defects in the past.
2 - Creating logical test cases
This step normally takes place only with more complex test cases. The tester may consider creating a logical test case that will cover the situation to be tested.
3 - Creating physical test cases
This step normally only takes place with more complex test cases. The tester may consider creating a physical test case for the logical test case.
4 - Establishing the starting point
During this activity, it may emerge that it is necessary to build a particular starting point for purposes of the test.
An overview of all featured Test Design Techniques can be found here.