Documentation Testing an Important Activity in Software Testing

Documentation testing falls under the category of non-functional testing. Documentation testing activity can take off right from the beginning of the software development process. If taken up from the beginning, defects in documentation can be effortlessly fixed with minimal expenses.

Poor documentation is as likely to cause problems for our customers as is poorly written code. Incorrect or poorly written or even missing documentation irritates the end users that tend to quickly form an opinion about the product. Hence quality of documentation bears a clear reflection on the quality of the product as well as that of the supplier who supplied it. The product can become a success, only

if its documentation is adequately tested.

For instance, a crucial step is left out of installation instructions, the install will fail. Even worse, the install may appear to succeed, but key features of the software will be inoperable. Or, if the software provides a great new feature but the documentation doesn�t tell the user how to set it up and invoke it, the feature might as well not even exist.

Software users rely on documentation. The documentation could consist of manuals, release notes, or help panels. Whatever the form, the content had better be correct. Sitting around a table and reviewing documentation is important, but just as in a code walk through, errors will slip past. By far the best way to discover these errors or gaps is through testing. However, this doesn�t necessarily mean we need any special activity. If we put some thought into it, our test execution can cover the code and the text that describes it, all at the same time.

The documentation testing generally includes two methods involving varying degree of complexity.

Method-1: Checking of spellings and grammar in the documents using available tools.

Method-2: Manual review of documents to discover errors, ambiguities or inconsistencies.

Key Target Areas for testing of documentation:

There are four main focus areas when testing documentation:

# Instructions
# Examples
# Messages
# Samples

If specific instructions are provided for certain activities, its likely we will have test scenarios defined for those same activities (if not, we probably should consider expanding our scenarios). When executing those scenarios, follow the documented instructions exactly, looking for errors or omissions.

Similarly, step-by-step examples may be provided to explain GUI screen inputs, clarify syntax for commands or other interfaces, show expected outputs, or illustrate other important points. If so, then it�s very likely we will need to exercise those same areas when we test the software. Mirror those examples in our tests. Watch for inconsistencies that might confuse the user, as well as outright errors. Keep in mind that any user following these examples closely will be trying to understand how something that�s new to them works. Any inconsistency could prove perplexing, and therefore is important to fix.

When we hit a problem, for example, an error message, we should verify that the documentation for the message is correct. The meaning of the error message may be obvious to us, because by now we are very familiar with the software. But a typical user most likely will not be as knowledgeable. So check to see if the error message documentation adequately explains the error and what should be done to address it.

Finally, samples are sometimes documented for such things as initialization or tuning parameter input files. When these are supplied soft copy via a companion CD-ROM or Web download, many customers will try to plug them in as is. If they are only documented in hard copy text, some users will implement only excerpts, and others will go so far as to type them into their system verbatim. In either case, we�ll need to try these samples during our test execution to make sure they are valid.

The approach for managing documentation defects we�ll find should be decided up front. Some organizations treat defects in manuals the same as those in code, using common defect reporting and tracking tools for each. Others use more informal means for managing documentation defects. Either way will work. The important thing is to acknowledge that these defects will exist, testing can find them, and that a feedback loop for reporting them must be in place.

Many More Articles on Software Testing Approaches

0 0 votes

Article Rating