I used to skimp on the documentation testing because I believe it detracts me from my “real” job, which is testing the program itself.

I am happy to admit that i was wrong!

Why is it important

• You will find more bugs than you expect. Surprisingly many bugs show up when a competent QA  THOROUGHLY checks the manual (or help guide) against the program. The writer looks at the program from a different angle than the developer and the QA, so the manuals will reveal different problems than the ones developers and QA look for.

• Heads up- Documentation testing doesnt always reveal sinificant new problems. QA who dont do a thorough job wont definately find many problems.

• It is an important source of real world combination test cases. One cant hope to test all the combinations of features or other options in the product, there are just too many. But one can test every combination that the manual describes as interesting and useful. Any time the manual even hints that the two aspects of the program work well together, test them together.

• Bug reports arising out of documentation testing are particularly credible. The manual is your company’s instruction to the customer on how to use the product. It is hard to dismiss a bug as “esoteric” when you report that the program failed while yo were following the manual’s instructions or suggestions, or checking one of its statements of fact. These are mainstream tets. These bugs are hard to defer- either the manual will change or the program will change.

Tips on testing the Manual

• Use the program exactly as the manual says. Enter every keystroke in every example. Customers make mistakes when they try to follow instructions. Feel free to make mistakes too.

• How does the computer respond? Bad error handling in the program will look worse when you how that it happens in response to an obvious, common mistake that several people will make when they try to follow the manual’s instructions.

• Try every suggestions, even if the suggestions are’t fully spelled out, step by step. Do what a reasonable customer would do who was trying to follow the suggestion.

• Check every statement of fact and every obvious inference from the stated facts, instructions, and suggestions. The manual is the product’s final specification, and the customer’s first place to check whether the program is working correctly.

It also pays to retest the documentation when you add a QA to the project. This keeps the manual current while the software is changing, and it educates new QA about the program.