Testing User

Manual

Sonali ChawlaAU12406020200

2P

Effective Documentation

Documentation is fully effective when it provides the following benefits:• Improves Usability• Lowers Customer Support Costs• Improves Reliability• Increases Maintainability• Improves Installability• Enhance Salability• Reduces Liability

The Documentation Tester’s Objectives

Reviewers of documentation are concerned with improving its accuracy, completeness, clarity, ease of use, and the degree to which it captures the spirit of the design. As a tester working with the manual, you are responsible for checking the technical accuracy of every word. Be on the lookout for confusions in the writing. Many of them stem from confusions and complexities inherent in the product's design. The writers must describe the product as it is. Look out, too, for missing features. Writers work from specifications, notes, and rumors. Developers try to keep writers up to date, but sometimes they forget to mention recently added features. You often discover changes much sooner than the writer—make sure these get into the manual.

Realize that you are a reviewer, not the writer. Most testers who think they know more about writing than the writer are wrong. It is your responsibility to find and identify problems, but after giving them a fair hearing, writer and programmer alike can choose not to follow your suggestions. In particular, you have no authority to demand stylistic changes. The writer can reject stylistic suggestions without justifying her decisions to you. You probably won't use a formal problem reporting system with the writer. Most comments will be on a marked up copy of the manual. Keep a copy of your comments and compare the next draft's changes to them. Talk with the writer about editing and commenting conventions. What can you adopt easily that would be helpful to her? For example, some proofreader's marks are useful. It also pays to ask for feedback about the comments you've made. Were they useful?

How Testing Documentation Contributes To Software Reliability

Many testers skimp on documentation testing because they think it somehow detracts from their "real" job, which is testing the program. They are sorely mistaken. • You’ll find more bugs than you expect• It's an important source of real world combination test cases • Bug reports arising out of documentation testing are particularly credible In your main test of the manual, you should sit with it at the computer and: • Use the program exactly as the manual says • Try every suggestion, even if the suggestions aren't fully spelled out, step by step. • Check every statement of fact and every obvious inference from the stated facts,

instructions, and suggestions.

Become The Technical Editor

If possible, the Testing Group should assign one person to the manual as technical editor. He might play other roles too, but in this role he is the primary technical reviewer, even if many other people also review the manual.

It is very common when two or more people check a product for none of them to take ownership of the task. Rather than improving the thoroughness of the review by adding another tester, thoroughness declines because everyone expects the other person to do the job. The technical editor should be encouraged to feel ownership of the technical accuracy of the book.

Working With The Manual Through Its Development

Stages The manual is developed in the four major stages as follows: • Conceptualization and initial design• Preparation• Production• Publication

Testing is concentrated in the preparation stage, with some spillover into production. You review the manual's content, not the layout, unless you have expertise in layout. You probably won't be involved in the initial design of the manual. You will rarely be involved in publication: the writer checks that the printed manual contains all the pages, none upside down, and so forth.

The First Draft

You will rarely see the first draft of the manual. Excellent writers often write a horrid first draft. It might be badly written and full of spelling mistakes and factual errors. It might be badly and inconsistently organized.If you are freshly assigned to a project, you don't know how the software should work and can't find any specifications, or if you are desperate, you might beg the writer for any documentation she has, even if it is first draft material. If she gives it to you, realize that it is for your use only. It is not for review, circulation, or criticism. It is not ready. Breach this trust and you will embarrass the writer and ensure that you never get first draft material again. The writer will find some comments helpful. Correct factual errors. If you think the writer doesn't understand something, volunteer to share your understanding. Treat this as a shared learning experience, not as a set of comments and criticisms. Finally, make no comments about the manuscript's style, structure, or organization unless you are explicitly asked for them. Even then, make them cautiously.

The Second Draft

This might really be the twenty-third draft but it's the first one circulated for review. It goes to the programmers, managers, and you. It is not ready for review by the user community, except for users who have been explicitly assigned to the development team. Do the following: • Make your structural comments early• Do a general review • Look for areas that need discussion • Look for violations of the spirit of the design • Look for things that mislead • Check the error messages • Look for confusions that reflect on the program

The Revised Second Draft(s)

Keep looking at the accuracy and effectiveness of the manual, as you did in the second draft. You will often be aware of program changes long before the writer—flag these for her in the manual.

There may be many revised second drafts, tuned to different types of changes. In one of these, the writer will polish the manuscript, cleaning up its style and doing the final organizational tweaking. You don't have to comment on the style and organization of the manual - your comments on accuracy and the design's spirit are more important. If you do have comments on style, they will be most effective just before the polishing draft. After polishing, the writer wants to get rid of inaccuracies and finish up. She may ignore further comments on style and organization.

The Beta Test Draft

This draft, or a revision addressing comments to this draft, will be the last one you'll see before production. In companies that don't rely heavily on beta tests, the final circulating draft is the user interface freeze draft, circulated after the software's design has frozen.Beta testers don't work for your company. They use the product in the same ways they would have had they bought it in finished form. They report their difficulties with the product, their suggestions for improvement, and any bugs they find. You should review their reports about the software and about the documentation. Up to this point the marketers, programmers, writers, and you have been making assumptions about how people will react to the product and about what they'll understand. Some of those assumptions are wrong. Some seemingly obvious aspects of the program may be incomprehensible to beta testers. Many changes to the manual come from user testing.

Users often complain if the documentation is not task-oriented. A task-oriented manual anticipates what users want to do with the product and explains how to do each task. It describes features in the context of using them to get specific tasks done. In contrast, a feature-oriented manual describes features individually, maybe in alphabetical order. Each section includes everything you ever wanted to know about one feature. Task-oriented manuals are much longer, but are more effective. If the product is so widely useful that people could do thousands of different types of tasks with it, the writer could never finish a task-oriented manual. As a compromise, writers often write a task-oriented tutorial that covers the most popular tasks. Beta test comments may convince the writer to improve the task orientation with more examples, more illustrations, a different index, or a different organization.

Production

Your main concern during production is that the document stay accurate. Someone in the documentation group will do the main proofreading of the laid out or typeset manuscript. If the company wants to release the product as soon as the software is complete and tested, documentation production must start 8 to 14 weeks before the program is finished.The program will change over those many weeks. Some parts of the manual will no longer be correct. Further, some bugs that everyone expected to be fixed will not be. Sections of the manual that assumed that a given bug would be fixed, in good faith and on good authority, have to be revised. Not all desirable changes can be made during production. The writer will change as little as she can get away with. You can get her to make more changes, and help keep the cost of the changes down, by designing the changes to match production constraints. As soon as a manual enters production, it stops being an organized collection of words. It is now a bunch of pages. There happen to be words and pictures on the pages, but each page is separate from all others. Each was carefully laid out; each will be photographed on its own.

The writer will not make changes that affect more than one page unless they are essential. At the other extreme, it is easy to make a change that affects only one line, without moving words down to the next line or needing words from the line above. If you can keep a change within a line, a paragraph, or a page, you have some hope of convincing the writer to make it. It is your responsibility to convince her that the change will stay within those limits. Be prepared to provide a suggested wording, and to show how the words fit on the lines. The wording must be stylistically acceptable to the writer. To make a change fit within a paragraph or a page, you will often have to cut out other words. This degree of editing is beyond the formal scope of your job. You can be asked to stop doing it. You don't have to do it and you shouldn't try unless you can do it well without taking too long. Another area to test during production is the index. The earlier you can get your hands on a draft index the better. You can improve the index's completeness by working with the draft manual and constantly trying to look things up in the index as you use the manual. Many words you expect in the index won't be there.

Post-Production

Some companies don't print the manual until after the software is finished. In these cases, there are no post-production tasks.

If your company does send the manual to print before the software goes to the duplicator, the writers probably have to write two further documents. One is a printed supplement that includes corrections, troubleshooting notes, and discussion of additional features. The typical supplement goes to print a few days before the disks go to the duplicator. Later-breaking information must go into a README file on the disk.

Apart from checking the accuracy of material in the supplement and README, your most valuable contribution during this period is identifying troubleshooting tips and explaining them to the writer. Every deferred bug is a potential idea for a troubleshooting tip. If you can describe the bug in a positive tone, and tell the customer something useful, it's a good candidate for the troubleshooting section.

Online Help

Most of what we've said about the manual is equally true for help. Here are a few additional notes. • Accuracy• Good reading• Help is a combination of writing and programming• Test hypertext links• Test the index• More on the index• Watch the style

Thank You