Look at ISTQB glossary definition (pdf!):
error guessing: A test design technique where the experience of the tester is used to
anticipate what defects might be present in the component or system under test as a result
of errors made, and to design tests specifically to expose them.
So, the tester should apply the old intuition to draw on her past and guess where the errors will hit this time. This sounds trivial on the one hand (learning from experience should be a basic human feature), but also very vague: suppose I have a tester with zero experience - can I teach her to guess errors? If I have 2 testers with the same experience - will they guess the same errors?
So, what can be done to improve your error guessing techniques?
- Improve your memory:
- List interesting error-types you come across
- Use existing bugs lists (I like the huge one provided as an appendix in Testing Computer Software, 2nd Edition)
- Improve your technical understanding:
- Go into the code, see how things are implemented, understand concepts like buffer overflow, null pointer assignment, array index boundaries, iterators, 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
- Errors in requirements
- Errors in design
- Errors in coding
- Errors in build
- Errors in testing (we never make mistakes, do we?)
- Errors in usage
A new team member was asked to plan tests for a web application screen that displayed items in batches of 25. I reviewed his test cases and asked him to add a test to search for missing items, or duplicated items around the "stitch" between the batches. After executing the tests, he came to me, saying that indeed the last item in each batch was duplicated, and appeared again as the first item in the next batch. He looked at me with awe and said "how did you know that this will happen?" I knew, because this is exactly what I missed when testing a paged-list a few years back - a customer found it for me... (Ego, back to sleep).
(CC)
4 comments:
from ISTQB foundation of software testing book:
"Error guessing is a technique that should always be used as a complement to other more formal techniques. The success of error guessing is very much dependent on the skill of the tester, as good testers know where the defects are most likely to lurk. Some people seem to be naturally good at testing and others are good testers because they have a lot of experience either as a tester or working with a particular system and so are able to pin-point its weaknesses. This is why an error-guessing approach, used after more formal techniques have been applied to some extent, can be very effective. In using more formal tech-niques, the tester is likely to gain a better understanding of the system, what it does and how it works. With this better understanding, he or she is likely to be better at guessing ways in which the system may not work properly.
There are no rules for error guessing. The tester is encouraged to think of situations in which the software may not be able to cope. Typical conditions to try include division by zero, blank (or no) input, empty files and the wrong kind of data (e.g. alphabetic characters where numeric are required). If anyone ever says of a system or the environment in which it is to operate 'That could never happen', it might be a good idea to test that condition, as such assumptions about what will and will not happen in the live environment are often the cause of failures. A structured approach to the error-guessing technique is to list pos-sible defects or failures and to design tests that attempt to produce them. These defect and failure lists can be built based on the tester's own experience or that of other people, available defect and failure data, and from common knowledge about why software fails."
Hmmm, "web application", "items in batches of 25", sounds familiar...
But I don't recall that bug - maybe it was before my time...
Techniques are not necessarily things that can be taught, but things that people actually do. Furthermore, I think error guessing can be taught. Maybe not like linear algebra, or maybe exactly like linear algebra - you learn most of the time from examples and doing exercises. Show new testers examples of such error guesses and give them some homework. If they're smart enough they'll get it.
Your example about the batches of 25 is foreseen. When testing such a feature I would easily test what happens when there are 0 items, several, some number closer to 25, one less than 25, exactly 25, between 25 and 50, exactly 50, maybe even 1000 items and 1001. It may be due to my general experience that I would come up with such tests, but not with direct experience of having seen exactly that bug happen before. Programming experience really helps because you know there is some if or case/switch in there that doesn't cover all the cases.
Anyhow, cool post!
Hello,
The Article on software testing method is nice detail information about thanks for Sharing the post about testing method . Software Testing Company
Post a Comment