TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
And earlier this week a "user" problem that a QA engineer was having turned out to be something similar.
There was a "bug" submitted for a help screen that had "old" content from the last version of our product (the "help" is actually an HTML file called to open in a new window from our web-based product). The QA engineer submitted the bug, I made the changes, checked the file back in, and returned the bug to him to close once he agreed it was fixed. After the next build, he returned the bug commenting that the help was still wrong. I looked in the build tree, saw that the "right" file was there, confirmed with the lead developer that he could "see" the correct file, and passed the bug back. After the next build, the QA guy returned the bug. Back and forth four or five times.
So, in the bug meeting Monday I brought a printout of the "fixed" file and showed it around (with some light-hearted banter and pretended exasperation that it was a conspiracy to keep me out of the build tree - this is a great development team with a collective sense of humor, so you may not want to try this at home). The lead and the QA and myself went out of the meeting together determined to get to the bottom of the problem.
Went up to engineering and looked on the lead's machine, saw the "fixed" file in the build tree. Called the BuildMaster to confirm the build script was correct. Looked on the QA engineer's machine, and saw the "wrong" help file. You can see this coming right?
Lead developer to QA engineer: "Have you cleared your browser cache?"
QA engineer (very quietly, with a look of extreme chagrin): "No."
Me (grinning): "Do I need to doc this?"
Dan
-----Original Message-----
From: bounce-techwr-l-129804 -at- lists -dot- raycomm -dot- com
[mailto:bounce-techwr-l-129804 -at- lists -dot- raycomm -dot- com]On Behalf Of Anita
Legsdin
Sent: Friday, October 03, 2003 12:35 PM
To: TECHWR-L
Subject: RE: Stupid users (was the "top this" thread)
Salient points from Mark, but I reply with another story (this one is true). I once was responsible for a portion of a user guide. Several bug reports were registered by the customer's testers, saying that various procedures just didn't work. After some investigation and much hair pulling, we discovered that the program (let's call it Program X) wasn't running at the time they tested our procedures! Now, because of pressure from the customer, all procedures begin with "Make sure Program X is running before starting the following procedure. Refer to [xref here] for instructions on how to start Program X." Duh? Evidently not.
RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for
competitive pricing or view a live demo at: http://www.ehelp.com/techwr-l3
---
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.
