Re: RE: Calling a Bug a Bug

Subject: Re: RE: Calling a Bug a Bug
From: "Beth Agnew" <Beth -dot- Agnew -at- senecac -dot- on -dot- ca>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Mon, 10 Mar 2003 22:49:52 -0500


Of course you write for your audience in terms that they find familiar.

As far as using bug numbers to help clients know what has been fixed,
every reported problem gets assigned a ticket number. In-house we may
refer to it as a bug number, but not all bugs are indeed errors in the
software that need to be fixed. Sometimes a reported problem is due to
any of a range of difficulties that are not necessarily OUR problem.
Even so, not every bug actually GETS fixed every time. It depends on the
priority and severity, how many customers are affected, etc.

Even the best QA can only find a certain number of problems. I've
discovered as many and more defects as QA just by using the product in
the course of documenting it. There are some problems certain types of
customers will never encounter. Hence "may" to indicate that if their
copy of the product doesn't show this error, they shouldn't worry and
start looking for it.

----- Original Message -----
From: Matthew Horn <mhorn -at- macromedia -dot- com>
Date: Monday, March 10, 2003 7:17 pm
Subject: RE: Calling a Bug a Bug

>
> >>I am very careful to make our product sound
> >>as stable and robust as possible. I never use the term "bug" in
> any
> >>document that will go to a customer.
>
> This particular tack can backfire in certain sectors. Server
> software springs to mind as an example. If your user is a hard-
> core developer, then you better use the word "bug" or they will
> have a hard time figuring out what you "may" mean.
>
> >>And I NEVER include the big long list of bug numbers that have
> been
> >>fixed in a release, e.g., 5122, 5123, 5134, 5145, 5166, 5278,
> 5982, etc.
>
> We do, for the server products anyway, since often these fixes are
> logged by large enterprise customers and that is the only way I
> can think of to communicate which bugs were fixed. How else would
> a customer who wants to know if bug #45678 was fixed find out?
>
> >>Heavy use of the word "may"
>
> I'd say this is a result of poor QA. If you don't know WHY and
> WHEN the bug occurs, how could it possibly be fixed?



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Order RoboHelp Office X3 by March 14 and receive a $100 mail-in rebate,
plus FREE WebHelp Merge Module and FREE iMarkup Software, for a
total giveaway value of $439! Order today at http://www.ehelp.com/techwr-l

Help celebrate TECHWR-L's 10th Anniversary starting this month!
Check out the contests at http://www.raycomm.com/techwhirl/special/contests/
Happy birthday to you, happy birthday to you, happy birthday TECHWR-L....

---
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.



Previous by Author: Re: Calling a Bug a Bug
Next by Author: Re: macron
Previous by Thread: RE: Calling a Bug a Bug
Next by Thread: Re: Calling a Bug a Bug


What this post helpful? Share it with friends and colleagues:


Sponsored Ads