docs in process, revisited

["Alex Silbajoris" <alsilba -at- hotmail -dot- com>]

Thanks for your responses about documentation fitting among development and 
testing.  It seems this company works differently from yours in these areas. 
 Only now are we beginning to write detailed specifications before the code 
is written; the tradition here for years was (still is, sometimes) to write 
the detail specs as an afterthought.

There is no help system in this particular product.  There is a Help menu 
button, with nothing behind it, because the original client design called 
for one, but we haven't been "tasked" with creating any system.  So, the 
missing help system complies with what the client has asked for, at least up 
to this point.

I should also explain that the client is a large government agency, which 
has its own internal conflicts and agendas, so we as a vendor must comply 
with changing requests and priorities.  They may have wanted something a 
certain way a year ago when the design specs were agreed upon, but now that 
element is forgotten.  All that remains is a menu item leading to nothing, 
like a vestigial leg on a boa.

By writing from what we observe in the interface, we are not trying to poke 
holes in the product.  That description might be more apt for our QA group, 
following test scripts and running stress tests.  In fact, it might be more 
accurate to say we seek holes in the test scripts - we try every command 
that might be tried by a clerk in the field.  This includes actions like 
submitting forms lacking needed data, to see what error message will 
display.  I have called this "walking through the forest and bumping into 
every tree."

Sometimes we find bugs that the test scripts don't see.  We have input to 
the QA process, so we can advise them (and development) when we find 
problems.

The project leader doesn't seem to understand that our practice of 
documenting what we see, not what we are supposed to see, means that we need 
more than just specifications and designs, we need to have our hands on the 
product.  And to attempt to use or sample the product before the development 
group says it's ready for release is like driving on a road that's still 
under construction.  It can be done with some success, but there can also be 
some wild stops.

My approach to this particular situation is to go ahead and capture screens 
and start documents, even if they are only placeholders.  I know they cannot 
be correct or complete yet, but at least they exist.  I will return to them 
later, when QA has the product, and fill them out with details and 
corrections that are not available now.

- A


_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Collect Royalties, Not Rejection Letters! Tell us your rejection story when you 
submit your manuscript to iUniverse Nov. 6 -Dec. 15 and get five free copies of 
your book. What are you waiting for? http://www.iuniverse.com/media/techwr

Have you looked at the new content on TECHWR-L lately?
See http://www.raycomm.com/techwhirl/ and check it out.

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.