Re: Attitude to defects

Andy Dingley wrote:
On 9 May, 05:26, James Dennett <jdenn...@xxxxxxx> wrote:

So many people arguing that defects are good.

No one is arguing that they're good, just that we need to describe
them in a neutral manner.

I can produce numerous quotes from this thread that say
otherwise, or at least say that defects are *not* bad.

But they're not.

Of course they're bad. Long association means that "defects" are
always going to have connotations of "bad" about them.

It's not just that we associate badness with them. The
defects are a failure to meet desired goals. Failure to
meet desired goals is pretty close to a definition of
what "bad" means in a business context.

So in an Agile world we need to stop using the term "defect" and start
calling them "issues", "sporks" or whatever. It's crucial that they
don't collect this same "bad by association" connotation because
that's unhelpful and wrong in this context.

They're bad because of what they are, not because of what
we call them. Your sporks are bad too. Which is why you
try so hard to avoid introducing them into the code.

For Agile (and especially Scrum), we don't have simple defects where
the code broke, we mainly have a backlog of things we haven't ticked
off yet - especially at the start of a project.

And you assume that your tests are perfect, apparently?

These are definitely
_not_ "bad" or "defects", they're our future business opportunities!

Failures caused by incomplete or inaccurate tests

There's no major need to separate "not done yet" from "done but not
working yet" (surprising though this might seem) -- they're all just
things that we still need to do by applying future dev effort towards
them. Labelling half of these as "bad" is neither necessary, nor
helpful.

If you want to beat up the bad developers, then do so by all means
(most coders need a touch of a good hot clueiron occasionally pour
cluer les autres) but you should find a better metric for targetting
it.

Faults are injected at all sorts of places in the process
of producing software.

If you focus on "faults" that causes you to do two things, both
harmful:

* It's a blame game. The function of QA becomes that of beating up
the developers. Not conducive to effective working.

* Faults need an objective standard to judge them against. This
standard is the waterfall spec and it soon assumes a rigid importance
exceeding that of the customer's current needs. Everything gets
focussed on delivering the "perfect" product, even if this perfection
is no longer what's wanted, needed or useful.



Should I assume that "defects are good" is a code phrase
meaning "it's better to know about a defect than not to
know about it"?

No. That's true, but it's a separate issue and not what we're talking
about here.

.

Relevant Pages

  • Re: Attitude to defects
    ... Long association means that "defects" are ... of producing software. ... Faults need an objective standard to judge them against. ...
    (comp.software.testing)
  • Re: High failure-rate for desktop PC power-supplies (Antec)?
    ... 2nd ethernet PCI-card looks just fine. ... burns or arcing or whatever. ... power supply under maximum load - to see some defects before it ... results in a failure. ...
    (microsoft.public.windowsxp.hardware)
  • Re: Sudden shutdown
    ... Important information is in the system logs. ... eliminate automatic restart might make future failures obvious. ... If dust caused a failure (especially after one year in a 70 degree ... a diagnostic tool to find other defects. ...
    (microsoft.public.windows.vista.general)
  • Re: quality control
    ... You expect 1 failure in 10,000. ... How did you go from 100 samplings of size 100 to the number 1400? ... that there are *no* defects, than what you get with this strong ... So even with a higher prior than specified, you cannot get close to 99%. ...
    (sci.stat.math)
  • Re: This Crashes RosAsm
    ... A test that demonstrates no faults is of little use. ... Rene and the rest of the RosAsm crew don't ... Defects are a fact of life in software. ...
    (alt.lang.asm)
Loading