Re: Template open/save behavior

Hi Folks -

Since I was a part of what reignited this discourse, I thought I'd jump back
in to add more fuel to the fire :)

John - Does the "industry" _not_ make a distinction between Custom-Designed
and Pre-packaged software? If it does, much of what you relate makes far
more sense. If the software is specifically written to address expressed
customer needs and fails to do so perhaps 'buggy' is appropriate, no matter
how well written.

OTOH, if the software is written for the general market and _works as
intended_ I don't see how that can be declared a bug simply because any one
user doesn't like the way it works. Applying that same concept in any other
industry seems just as defiant of logic as it does here... Poser-

If someone purchases a BMW Z4 [insert preferred vehicle here] and determines
after-the-fact that it can't effectively tow their 40' boat, does that make
the car "buggy"?

I'd be more tempted to call it a bad decision on the part of the purchaser.
Further, my experience has been that the software industry (in general) is
not sufficiently benevolent as to assume responsibility for the user's
inappropriate choice.

As far as:

Well, that's the opposite of what the majority of the industry believes. If
I paid for it, it's *my* software. I'm the customer, the
designer/manufacturer are working for me. I say what I want, not them.

If referring exclusively to custom software, fine, but any EULA I've ever
read for 'shrink-wrap' software explicitly states otherwise... The user is
paying for the license to *use* the software & agreeing to any number of
restrictions that the developers *would not* have any legal right to impose
unless they retained ownership to the software.

Regards |:>)


On 2/17/06 1:33 AM, in article C01BB956.2E743%john@xxxxxxxxxxx, "John McGhie
[MVP - Word and Word Macintosh]" <john@xxxxxxxxxxx> wrote:

Hi Beth:

On 16/2/06 6:33 AM, in article C018C1FF.27F6A%bethrosengard@xxxxxxxxxxxxx,
"Beth Rosengard" <bethrosengard@xxxxxxxxxxxxx> wrote:

The one most commonly cited internationally is:
http://www.istqb.org/fileadmin/media/glossary-1.0.pdf

Wow! Now that is really interesting. All this time I have been arguing over
the meaning of the term "bug" and taking your word for the meaning of the
term
"defect". But according to the source you've quoted, the meaning of "defect"
is synonymous with what you have called "Coding Defect" and I have called
"bug"!

Ummm... No, it very specifically did NOT say that :-)

Let me back up a minute and explain (for anyone else still reading this :-)
how I came to that conclusion. On the page referenced above, the entry for
"bug" says "See defect." The entry for "defect" says:

A flaw in a component or system that can cause the component or system to
fail to perform its required function, e.g. an incorrect statement or data
definition. A defect, if encountered during execution, may cause a failure
of the component or system.

It said "A flaw in a component or system that can cause the component or
system to fail to perform its required function..."

It did NOT say "A _coding_ defect...". This distinction is utterly critical
to software quality management. A Defect is anything the customer didn't
want (even including a schedule or budget overrun). The *cause* of the
defect gets worked out later in the process.

Does it do what the CUSTOMER really wanted? If yes, it's good. No matter
how weird the software's behaviour, if that's the way the customer wants it,
it is good.

If not, it's a Defect/Bug. No matter how reliable, stable, or conforming to
specifications it is, if the customer didn't want it that way, it's a bug.

If it's a bug, then we can sit down and work out how it got that way. We
might at that stage discover it's a coding bug, but it's more likely these
days to be a design bug or a specification bug or an analysis bug. It often
IS a "systemic failure", where the "system" in question is the system by
which we manage the software development process.

The required function is, of course, determined by the software
designer/manufacturer. It's *his* software.

Well, that's the opposite of what the majority of the industry believes. If
I paid for it, it's *my* software. I'm the customer, the
designer/manufacturer are working for me. I say what I want, not them.

In the case of "shrink-wrap" software (i.e. Off-the-shelf, ready to install
software) such as Microsoft Office, nothing changes. If it doesn't do what
the purchaser wants, it's defective/faulty/flawed/buggy.

Since the sad reality of life is that no-one could afford to make or buy
software that didn't have at least SOME bugs in it, every manufacturer heads
for their lawyers to write an End User Licensing Agreement that basically
says "It is like it is, and by installing it, you indicate that you agree
that you wanted it just like that." Doesn't alter the state of the
software; it just gives us the option of either not buying it; or not
complaining about it. But it's still buggy :-)

Now it may be that the *user* would like to see a different result and
believes that the designer has incorrectly understood the required function.
From the user's standpoint, the software has a design flaw (or defect), but
not a bug.

Yep. That's a bug. One of (I think it's 29) different causes of a defect,
but it's still a bug.

I think that the International Software Testing Qualification Board" needs to
update its glossary and redefine "bug" or redefine "defect", because as the
Glossary now reads, a bug is exactly what I have contended all along.

You be sure to write and tell 'em :-)

I ain't weepin' :-). "Bug" absolutely HAS had that meaning within the
industry and your source proves it.

Oh. Well, you be sure to alert the ISO and the IEEE to this new discovery.
I suspect it will come as something of a shock to all of us working in the
industry, after all those years of trying to make what the customer wanted;
but there you go :-)

Cheers

.

Relevant Pages

  • Re: Template open/save behavior
    ... "defect". ... Does it do what the CUSTOMER really wanted? ... specifications it is, if the customer didn't want it that way, it's a bug. ... days to be a design bug or a specification bug or an analysis bug. ...
    (microsoft.public.mac.office.word)
  • Re: To be a bug or not to be a bug [Was: Re: Template open/save behavior]
    ... What I say in this forum is often from the standpoint of being a "customer" ... Since I have some exposure to the software industry I know ... behaviour" that IS a defect. ... When it comes to the meaning of "bug", you and I, John (or if you ...
    (microsoft.public.mac.office.word)
  • Re: Template open/save behavior
    ... A defect, if encountered during execution, may cause a failure ... Does it do what the CUSTOMER really wanted? ... specifications it is, if the customer didn't want it that way, it's a bug. ... days to be a design bug or a specification bug or an analysis bug. ...
    (microsoft.public.mac.office.word)
  • Re: Template open/save behavior
    ... A defect, if encountered during execution, may cause a failure ... Does it do what the CUSTOMER really wanted? ... specifications it is, if the customer didn't want it that way, it's a bug. ... days to be a design bug or a specification bug or an analysis bug. ...
    (microsoft.public.mac.office.word)
  • Re: VS 2003 Very Slow
    ... charges that are ordinarily incurred for support calls may be canceled ... This implies to me if you find a NEW problem you still pay $250 for the provilege of telling MS about their mistake. ... part is there if a bug tht is unrelated to an issue the call is about gets discovered or if customers raise several issues of which just one is a bug and the others are unrelated. ... But paying for customer support makes us pay for the privilege of de-bugging your software. ...
    (microsoft.public.dotnet.languages.vc)