As I attempt to document the 16 new reports, it becomes painfully obvious to me that these reports have "issues". The new reports have all been copied from the first one created, and evidently each programmer assigned to each report didn't see the "hover" messages above date fields that say "Defaults to the first of the month" and "Defaults to the current date". So maybe three of the reports really do default those dates, but the rest do not. So either really do default the dates or get rid of the damned "hover" messages.
OK, I can work around that problem by checking each report and documenting whether or not it really does default the dates. I could ignore the entire situation and pretend I didn't notice the hover messages. After all, they only show up in a bright yellow box when you happen to move the cursor over the fields. But worse yet is after I run these queries, about four of them have math problems when I hit the Print button. The report generates into an Adobe Reader format, BUT on the screen with the search results, a field that shows an 'average' lists that average as 67%. That part is correct. However, on the generated report, that average shows up as 50%. Now how is that possible? I note these issues in our tracking software. The analyst then sees what he missed when he QA'd the reports. He calls the programmer. She's not happy.
This morning I ran into her in the hallway and was greeted with a "Since when are you an analyst?" statement. You know...sort of kidding, but sort of NOT kidding? OK, I admit...I'm a mere lowly tech writer. But how can I document what doesn't work or what doesn't add up? I'm a whiz with the screen capture software...I can fake a screen to make it the software look like it can save the world. But is that the right thing to do? My choices are to:
1. Fake it to look correct.
2. Document it "as it is", mistakes and all.
3. Skirt the issue and just give a generic "here's what we did"--no screen shots.
4. Bring the problem to the attention of the analyst, even though he's already passed it onto the customer to look at (and chances are, the customer doesn't test it very well either).
So maybe next time I'll do the screen shots complete with all the nice little Oracle errors that pop up, or the totally blank reports that are generated. Maybe I'll leave the simple math errors for the world to see. Wonder what they'd say to me then..."What...are you an idiot? You can't see that this thing doesn't work right? Why didn't you say something?"
...and I'll just say, "What am I???...an analyst????".
3 comments:
FIRST, FINALLY another post.
SECOND, the last company I worked for had someone prepare a training manual for the new system. The screen shots were taken from the training system, which had been used by some of the salesguys (read a step-below used cars sales).
The people that produced the training manual got an angry call from our Florida office that was using it.
Apparently one of the screen shots of inputting a new customer had a new customer name of..........
"Wet Hot Mama"
Apparently people in Florida have no sense of humor.
Report everything, regardless of who it pisses off.
I can't tell you how many times I had to clean up the test data just to get an appropriate screen shot.
I sent you an email on this one. In my humble opinion... your organization is ISO 9002 certified. Every employee has a responsibility to ensure that they are doing what they can to follow processes that produce a quality product that meets the customers needs. If the programmer had paid better attention in the first place, this wouldn't be a problem. If the analyst had actually tested the screen/report, this wouldn't be a problem. I mean, we're not talking about subtle issues here. These are pretty darn obvious and should have been included on ANY test plan. The fact that the SCR got so far through the process that the documentation specialist (NOT AT ALL LOWLY, I might add) shows two things: one, they have one damn good documentation specialist, and two, the people ahead of you in the process need to be retrained.
I wonder how long I can type in this little box...
As a certified Quality organization, it takes everyone to work together to put out the best product. And your co-worker, whether kidding or not, needs to understand that it doesn't matter who finds the problem with the application...the person most qualified to fix the problem needs to simply set out to fix it. And I'm no longer just talking about the reports...but also the process for putting out a good product.
And that's all I have to say about that.
I use nicknames sometimes, but not like that! I'm more worried about accidentally leaving a real SSN on a screen shot. But heck...few
users ever see my documentation anyway! They keep it hidden away where very few have the access to see it.
The programmer and analyst may have gone so far as to have actually run both the queries and the printed reports--but just never bothered looking to see if the data made sense or even matched each other.
Post a Comment