Tester Tested !: Your search for Bug Free Software ends here

Tester Tested !: Your search for Bug Free Software ends here: Test 2008 was a scintillating software testing conference. I never slept before 2 AM every night around the conference dates. I had great di...

Error Guessing

In software testing, error guessing is a test method in which test cases used to find bugs in programs are established based on experience in prior testing. The scope of test cases usually rely on the software tester involved, who uses past experience and intuition to determine what situations commonly cause software failure, or may cause errors to appear. Typical errors include divide by zero, null pointers, or invalid parameters.

Error guessing has no explicit rules for testing test cases can be designed depending on the situation, either drawing from functional documents or when an unexpected/undocumented error is found while testing operations.

Error Guessing is the ability to find errors or defects in the AUT by what appears to be intuition. In fact, testers who are effective at error guessing actually use a range of techniques, including:

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

Error guessing is a skill that is well worth cultivating since it can make testing much more effective and efficient - two extremely important goals in the testing process. Typically, the skill of Error Guessing comes with experience with the technology and the project. Error Guessing is the art of guessing where errors can be hidden. There are no specific tools and techniques for this, but you can write test cases depending on the situation: Either when reading the functional documents or when you are testing and find an error that you have not documented.

Importance and Consequences of bugs

IMPORTANCE OF BUGS: 

 The importance of bugs depends on frequency, correction cost, installation cost, and consequences.

1. Frequency: How often does that kind of bug occur? Pay more attention to the more frequent bug types.
2. Correction Cost: What does it cost to correct the bug after it is found? The cost is the sum of 2 factors: (1) the cost of discovery (2) the cost of correction. These costs go up dramatically later in the development cycle when the bug is discovered. Correction cost also depends on system size.
3. Installation Cost: Installation cost depends on the number of installations: small for a single user program but more for distributed systems. Fixing one bug and distributing the fix could exceed the entire system's development cost.
4. Consequences: What are the consequences of the bug? Bug consequences can range from mild to catastrophic.

A reasonable metric for bug importance is

Importance= ($) = Frequence * (Correction cost + Installation cost + Consequential cost)

• CONSEQUENCES OF BUGS: The consequences of a bug can be measure in terms of human rather than machine. Some consequences of a bug on a scale of one to ten are:
  1. Mild: The symptoms of the bug offend us aesthetically (gently); a misspelled output or a misaligned printout.
  2. Moderate: Outputs are misleading or redundant. The bug impacts the system's performance.
  3. Annoying: The system's behaviour because of the bug is dehumanizing. E.g. Names are truncated orarbitarily modified.
  4. Disturbing: It refuses to handle legitimate (authorized / legal) transactions. The ATM wont give you money. My credit card is declared invalid.
  5. Serious: It loses track of its transactions. Not just the transaction itself but the fact that the transaction occurred. Accountability is lost.
  6. Very Serious: The bug causes the system to do the wrong transactions. Instead of losing your paycheck, the system credits it to another account or converts deposits to withdrawals.
  7. Extreme: The problems aren't limited to a few users or to few transaction types. They are frequent and arbitrary instead of sporadic infrequent) or for unusual cases.
  8. Intolerable: Long term unrecoverable corruption of the database occurs and the corruption is not easily discovered. Serious consideration is given to shutting the system down.
  9. Catastrophic: The decision to shut down is taken out of our hands because the system fails.
  10. Infectious: What can be worse than a failed system? One that corrupt other systems even though it doesnot fall in itself ; that erodes the social physical environment; that melts nuclear reactors and starts war.