Error Guessing is a test case design technique where the tester has to guess what faults might occur and to design the tests to represent them.
Purpose
The purpose of error guessing is to focus the testing activity on areas that have not been handled by the other more formal techniques, such as equivalence partitioning and boundary value analysis. Error guessing is the process of making an educated guess as to other types of areas to be tested.
For example, educated guesses can be based on items such as metrics from past testing experiences, or the tester's identification of situations in the Functional Design Specification or Detailed Design Specification, that are not addressed clearly.
Examples
Though metrics from past test experiences are the optimum basis for error guessing, these may not be available. Examples of error prone situations include:
initialization of data, (e.g., repeat a process to see if data is properly removed),
wrong kind of data, (e.g., negative numbers, non-numeric versus numeric),
handling of real data, (i.e., test using data created through the system or real records, because programmers tend to create data that reflects what they are expecting),
error management, (e.g., proper prioritization of multiple errors, clear error messages, proper retention of data when an error is received, processing continues after an error if it is supposed to),
calculations, (e.g., hand calculate items for comparison),
restart/recovery, (i.e., use data that will cause a batch program to terminate before completion and determine if the restart/recovery process works properly),
proper handling of concurrent processes, (i.e., for event driven applications, test multiple processes concurrently).
Purpose
The purpose of error guessing is to focus the testing activity on areas that have not been handled by the other more formal techniques, such as equivalence partitioning and boundary value analysis. Error guessing is the process of making an educated guess as to other types of areas to be tested.
For example, educated guesses can be based on items such as metrics from past testing experiences, or the tester's identification of situations in the Functional Design Specification or Detailed Design Specification, that are not addressed clearly.
Examples
Though metrics from past test experiences are the optimum basis for error guessing, these may not be available. Examples of error prone situations include:
initialization of data, (e.g., repeat a process to see if data is properly removed),
wrong kind of data, (e.g., negative numbers, non-numeric versus numeric),
handling of real data, (i.e., test using data created through the system or real records, because programmers tend to create data that reflects what they are expecting),
error management, (e.g., proper prioritization of multiple errors, clear error messages, proper retention of data when an error is received, processing continues after an error if it is supposed to),
calculations, (e.g., hand calculate items for comparison),
restart/recovery, (i.e., use data that will cause a batch program to terminate before completion and determine if the restart/recovery process works properly),
proper handling of concurrent processes, (i.e., for event driven applications, test multiple processes concurrently).
