Re: on-line testing plan

[Anthony Markatos <tonymar -at- HOTMAIL -dot- COM>]

Lesley Roth asks:

 I need help with developing a test plan for our on-line help system.  I
will not be writing the test plan but would like to be in on the test
plan process from the beginning.   I am new to the concepts of help
authoring and testing.  Our programmers/testers need some guidance too
and they are looking to me.  Might someone be able to point me in the
direction of some good books on testing specifically for on-line help?

Tony Markatos replies:

I do not know of any books for developing test plans specificaly for
on-line help systems.  However, I have done a lot of research in the
area of software testing/test planning - specifically, the role of
technical writers in doing such.  I can not remember the title of the
book, but a work by Hetzel (last name) is an all time favorite among
software quality people.  I liked it because it does a very good job of
addressing the issues and is also farily easy to read.

Note:  The "natural" area for technical writers become involved in
testing is in Functional Testing.  This is were we evaluate the software
from an end user's perspective.  This testing is also called "Black Box"
testing.  Black box means we evaluate the software without looking at
the code ( vs White Box testing were we do look at the code).
Functional testing can be done at various points in the testing cycle.
I have always done Functional Testing during Systems and Module level
testing.  However, it can also be done during Acceptance testing.

What is the natural relationship between Functional (Black Box) testing
and technical writing?   The key concept is not everything can be tested
(this would take forever even if we could ID all possible permutations).
This is especially true for Functional testing which is more "bigger
picture" oriented that is White Box testing.  So, the major tasks is to
identify what must be tested.  And the "must tests" are always based
upon the essential tasks that the end user must perform with the system.
There are two possible inputs to the process of identifying these
essential tasks: the requirements specification, and the end user
manual.  Now 99.9% of the time the requirements specs either do not
exist or are so poorly done that they are of little use to anyone.
Therefore, if the end user manaul has any value at all, it is going to
be used as the basis for determining what is to be tested during
Functional testing.  This is where a technical writer comes in.

Tony Markatos
(tonymar -at- hotmail -dot- com)






______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com