Re: Do you do QA?

[Stuart Burnfield <slb -at- FS -dot- COM -dot- AU>]

Karen Mayer wrote:
> Me neither. We would be expected to *write* those QA procedures, not
> just document them. Meaning, design the tests.

> As far as I can tell, the reason for doing this is to include writers
> in the design phase of projects and to get the most out of the current
> staff, since we don't have the budget to hire real QA people.

This makes a bit more sense. Getting you involved in the design phase is
an excellent idea. We used to have problems doing QA because we didn't
have a clear written statement of what the software was supposed to
acheive, who would use it, what tasks they were likely to do, and so on.
This makes QA very hard, as you are limited to following a checklist
approach -- test every menu option, enter data in every field, see if
it looks OK.

There are several different ways to approach testing. For example:

- standard checklist of functions, menus, fields
- task based. What are the common tasks that users will do ("add a new
  user", "Create an index", etc)
- evil genius. Find someone with a nasty streak and a talent for making
  software break, and turn them loose.
- day-to-day use. Get someone to use the software regularly over for at
  least a few weeks.

There are others, but you get the idea. If resources are limited (and
aren't they always), you get much better value from spending some time
on several different approaches than you do from doing one sort of
testing exhaustively.

As a writer you can contribute to QA by helping to define the tasks
early, so the testers know what the thing is *supposed* to do. You
will probably be one of the first people outside the developers to
use the software day-to-day. You might even be an evil genius.

What  wouldn't recommend is that you do the checklist testing. Anyone
can do this sort of testing, and I think it works against your job as
documenter. We should be thinking about tasks and goals, and it's
very easy to slip into documenting menus and forms.

If your company can't afford a dedicated QA person, what about the
customer support people? Someone will have to take support calls and
help with installation problems. These people have to learn the
software some time. Why not use QA as a way to introduce them to
the new product?

Regards
---
Stuart Burnfield (slb -at- fs -dot- com -dot- au)        Voice: +61 9 328 8288
Functional Software Pty Ltd             Fax:   +61 9 328 8616

                  TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send administrative commands
         ALL other questions or problems concerning the list
       should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-