OK, so for those of you who haven't been following this story...

I was asked to write a couple of trivial little programs to help us with 
our electronic data archiving processes. The programs themselves are 
quite easy [modulo Haskell's strange exception handling]. But, 
obviously, we have to test them. Writing the actual tests isn't even 
that difficult.

However, in addition to writing what the actual tests are, I also have 
to produce a big document that describes

- Who we (the company) are.
- Where we are.
- What the software is.
- Who write the software.
- Why they wrote the software.
- How the software was designed.
- What the software will be used for.
- Who the software will be used by.
- How they will be trained in the use of the software.
- How we will document that they have been trained in the use of the 
software.
- What process the software replaces.
- Why this is better.
- What we need the software to do.
- How we know the design of the software matches these needs.
- What testing we're going to do.
- Why testing is necessary.
- What functionallity will and won't be tested.
- Which tests relate to what functions.
- What will happen if all the tests pass.
- What will happen if any tests fail.
- What documentation we will generate.
- Where this documentation will be stored.
- How long it will be stored for.
- What we will do if we make changes to the software.
- How often we will review all this documentation.
- How often we will retest the software.
- Many, *many* other things I can't even remember.

All of which is probably tediously necessary for something like, say, 
our project management system, which took over a year to develop. [Let 
us not dwell on the fact that they wrote the software and *then* wrote 
the system design documents...] However, for a trivial 2-page program, 
this is an insane level of overkill!

Well anyway, what is supposed to happen is this:

- You decide you're going to make some software.
- You perform an elaborate requirements gathering process.
- You generate lots of documentation of this process.
- You design your software.
- You produce a "tracability matrix" which depects how each design goal 
directly relates to end user requirements.
- You write the actual software [surely the *easy* part?!]
- You write a Plan document which contains
   - A description of the requirements gathering process.
   - A reference to the User Requirements Document.
   - A reference to the Design Specification Document.
   - The Tracibility Matrix.
   - A reference to the Test Scripts.
- You carry out the Test Scripts.
- You write a Report document which contains
   - A summary of the test results.
   - What you're going to do about any problems.
   - Can we use the software now?
   - Do we have to implement any workarounds?
   - Are there any functions of it we can't use?
   - How often will we retest it?
   - etc.
- You write yet another document, the Release Memo, stating the date on 
which the software is officially "released".

[Even this is in fact a slight simplification of the actual process.]

[Perhaps now you see why just sitting down in a room by yourself, 
writing the program you think you need, and then making up the User 
Requirements and Design Specification afterwards is actually a serious 
violation of procedure. Not that this is an issue at HQ...]

Needless to say, I am utterly struggling at this point! The UK has never 
done the full test process before; what usually happens is that HQ do 
the test process, and they just hand us a test plan to execute, we 
execute it, sign it, and they do the rest. Nobody here has ever 
*written* all this documentation before... Signing a couple of test 
scripts is a tad different to writing an entire spec/design/test/review 
package from scratch!

Well anyway, I'm having a lot of trouble deciding on exactly how to do 
the test scripts to best effect. And Word is doing its very best to be 
maximally obstructive. And I am really struggling with this damn report!

So anyway, I need to get this document signed. And it looks to me like 
QA is the only real problem here. As long as the document looks remotely 
plausible, the others will sign. So I thought I'd go ask QA for some 
help with getting this thing right. [I have a hopelessly tight deadline 
on this thing...]

However, much to my dissappointment, it rapidly became *crystal* clear 
that QA have absolutely *no intention* of doing anything whatsoever to 
help me. I asked them "I could do it this way or I could do it that way; 
what do you think?" And they said "I don't know, what do you think you 
should do?" Great! But when I submit the thing for actual review, it 
will be "oh, you can't do THAT". Don't tell me what I can do, just what 
I can't.

Basically, they don't want to tell me what the correct thing to do is; 
they want to review the document, reject it, and leave me guessing what 
I'm supposed to do to fix it. Gee, thanks a lot! And all the while, I've 
got the guys in the lab jumping up and down on me that they need to 
start using this software.

Does anyone *else* feel that it's them verses the *entire* world every 
single day of their lives??

(That QA guy is *really* intimidating by the way...)

Post a reply to this message