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.
Yes, I've tested software for bugs, and I've also worked with folks
whose entire job is software testing.
The whole concept of a bug being "rejected" speaks to a faulty process.
The company should have a clear definition of what a bug is. When the
tester finds one, someone has to decide (a) whether it needs to be
fixed, and (b) whether to delay the release if necessary (two separate
decisions). A "no" in either case doesn't negate the tester's work or
the bug's existence.
I don't think the software tester should make either of those decisions.
Neither should the software developer. But you're describing a situation
where they have *input*, and that's as it should be.
-----Original Message-----
From: Dana Worley (MVP/JB)
Sent: Friday, August 12, 2011 3:15 PM
To: techwr-l -at- lists -dot- techwr-l -dot- com
Subject: RE: Advice on software testing?
Dan Goldstein wrote:
/Not sure what "position" can a tester have on a bug, other than, "The
bug exists, and here are the ramifications." /
I would surmise that you've never tested software, or worked with anyone
who is passionate about testing software!
As Peter said, as a tester I may turn in a bug that the engineer or the
"bug vetter" deems is not an issue. If I care about the quality of work
I am doing, and the quality of the product that will eventually be
shipped out, then I may very well take issue with my bug being rejected.
As with most things in life, you have use good judgment on when to stand
your ground and when to walk away.
FWIW, when we get close to a release, I sit down with every one of my
testers and ask them whether or not they feel a product is ready to
ship, or how close the product feels to being stable. These folks are
working with the software day in and day out, and have a pretty good
idea whether or not we should be comfortable shipping. In one of the
classes I took, the instructor said that in one company she worked with,
the testers would draw on the board each day how they were "feeling"
about the stability of the software -- smiley face, sad face, angry
face, etc. :-) We haven't done that, but I do rely on their input along
with risk analysis, market demands, and commitments when making a
decision on when to ship.
This message contains confidential information intended only for the use of the addressee(s). If you are not the addressee, or the person responsible for delivering it to the addressee, you are hereby notified that reading, disseminating, distributing, copying, electronic storing or the taking of any action in reliance on the contents of this message is strictly prohibited. If you have received this message by mistake, please notify us, by replying to the sender, and delete the original message immediately thereafter. Thank you.
Create and publish documentation through multiple channels with Doc-To-Help.
Choose your authoring formats and get any output you may need. Try
Doc-To-Help, now with MS SharePoint integration, free for 30-days. http://www.doctohelp.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
