Error Guessing

What is an error?

  • The occurrence of an incorrect result produced by a computer
  • A software error is present when the program does not do what its end-user reasonably expects it to do.
  • A human action that produces an incorrect result. [IEEE 610].

Testing based on error guessing

  • Test design technique where the experience of a tester is used to find the components of software where defects might be present

It is the process of using intuition and past experience to fill in the gaps in the test data sets.

Purpose of error guessing

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 as important as equivalence partitioning and boundary value analysis because it is intended to compensate for the inherent incompleteness of those functions.

As equivalence partitioning and boundary value analysis complement one another, error guessing complements both of these techniques.

Used techniques

Testers who are effective at error guessing use a range of techniques:

  1. Knowledge about the AUT(Application Under Test), such as the design method or implementation technology
  2. Knowledge of the results of any earlier testing phases (particularly important in Regression Testing)
  3. Experience of testing similar or related systems (and
    knowing where defects have arisen previously in those systems)
  4. Knowledge of typical implementation errors (such as division by zero errors)
  5. General testing rules

How to improve your error guessing techniques?

Improve your memory:

  • List interesting error-types you come across
  • Use existing bugs lists

Improve your technical understanding:

  • Go into the code, see how things are implemented, understand concepts like buffer overflow, null pointer assignment, array index boundaries, iterator, etc
  • Learn about the technical context in which the software is running, special conditions in your OS, DB or web server.

Remember to look for errors not only in the code. Look for:

  • Errors in requirements
  • Errors in design
  • Errors in coding
  • Errors in build
  • Errors in testing
  • Errors in usage

How to design test cases?

  • There are no specific tools to use
  • Test cases can be designed depending on the situation:
    • It can be drawn from functional documents
    • It can be drawn when an unexpected/undocumented error is found while testing operations
  • Historical data about defects that have been found in code that the same developer or developers have written in the past can be used
    • For example, if you know from past experience that developer A sometimes forgets to use “==” instead of “=”, and developer B sometimes forgets to check pointers for NULL after allocating memory, then those are defects that you might wish to look for in any code written by those two developers in the future.


  • Different people with different experience will show different results
  • Different experiences with different parts of the software will show different results
  • As tester advances in the project and learns more about the system, he/she may become better in Error Guessing

Pros and Cons

  • (+) Highly successful testers are very effective at quickly evaluating a program and running an attack that exposes defects
  • (+) Can be used to complement other testing approaches
  • (+) It is a skill that is well worth cultivating since it can make testing much more effective and efficient
  • (-) Testing experience is essential
  • (-) Relies on tester’s intuition

Example 1

  • Requirement 1: Contact No. should be numerals and should be not less than 10 characters
  • The application is having Contact No. field
  • These are the Error guessing technique:
    • What will happen if you left Contact No. blank?
    • What will happen if you enter other than numerals?
    • What will happen if you enter less than 10 numerals?
    • What will happen if you enter alphabets in between the digits?

Example 2

  • Requirement 2. The entered arrival date should be numerals and in a valid range.
  • The application has an arrival date field
  • These values for testing can be used:
    • 2011.04.31 – April has only 30 days
    • 2011.02.29 – 2011 is not a leap-year

Was this article helpful?

Related Articles