Re: Attitude to defects

On 10 May, 11:32, Wayne Woodruff <w...@xxxxxxxxx> wrote:

If it quacks like a duck and walks like a duck, it's a duck.

What if it's not a duck, you just found it floating in the duckpond?
No-one calls fish ducks, even if the chef's job is still to catch and
cook them regardless.

Bzzzzzt. I completely disagree with this 'philosophy'. There's a BIG
difference in the COST between "not done yet" and "done but not
working yet".

Is there? My costs vary most according to _where_ I find and fix it,
not according to _what_ it is.

If a tester is testing a feature that is not complete
and writes a bug and development says "well that part is not done"
you've wasted the testers time to write it and the developers time to
analyze it.

That's a waste certainly, but it costs the tester the same time and
effort no matter why it got there.

The cost-saving derives from the fact that we know the "not done yet"
list _before_ we start, and we don't (and can't) know the "done but
broken" list. By paying attention to these lists when scheduling
effort, you can avoid wasting it on the "not done yets". This is why
we're still right to see "done but broken" as expensive and to be
avoided (I'm not saying these things aren't bad).

So testers need to see the list of dev work needing to be done as two
things: stuff they ought to test for, and stuff they shouldn't yet
waste effort on testing. Developers don't need to distinguish though:
it's all just lumps of work needing to be done.

The Agile benefit comes when we have to deal with fluid requirements.
Don't waste effort on separating the sheep and goats, just treat every
shortfall (a not-done, a broken, and a did-it-but-then-they-changed-
the-spec) as units of work. Otherwise we freeze the waterfall into an
icicle and too much becomes focussed on meeting "The Spec", even when
the customer has stopped caring about it.

Customers don't care _why_ something doesn't work, they just want it
to do what they need or want. Many smarter customers don't even care
too much about how many (negative) bugs are in a product -- instead
they care about how many usable (positive) features it has instead. Of
course most customers are sadly already poisoned by the vendor's
support consuitants and their focus on the easily-measured (bugs) more
than the useful (features).


Testing is not about beating up developers. If that's how it works
where you are, I feel bad for you.

In practice it often is. Good practices will discourage this. It's a
common trap for teams to fall into though.


In my world, testing is QC, not QA

Interesting. What's your "testing" here? Manual or automatic
regression? In my currrent world, the one thing "testing" isn't is
QC. Our formal testing within the QA team is heavily manual, expensive
and slow and we just can't afford the delays to have them involved in
a QC role. We have to fly this entirely within the Dev and Support
teams, based solely on the automatic and rapid QC testing we have in
there (so far it's working). QA's role has become more oriented
around ongoing product development and certainly _not_ end-of-line QC.

We clearly need to automate the QA team's work much more, and if we're
going to rely on it so heavily we have to make sure our Support QC
auto-testing is adequate. It would also be nice for some management
to appreciate that QA's role has already shifted so much though. It's
an interesting approach (and a new one for me) and so far it seems to
be working pretty well. It's also a more interesting working life for
the QA people to be involved in changing and developing the product,
not just counting beans.


There is no such thing as a perfect product and we all recognize that.

Agile says that there is (conceptually), we just don't know exactly
what it is, we know we aren't there yet, and we know that by the time
we are, it will have moved on. We keep sight of it though and
continually make sure that we keep heading in the right direction
towards it.

Waterfall accepts that there's no perfect product too, so instead they
erect a Golden Calf spec to stand in for it instead. Then everyone
focusses on worshipping the golden calf and forgets that it's only an
idol, not the real target.

.

Relevant Pages

  • Re: Why is OO popular?
    ... What the customers initially think they want is sometimes ... > software developers? ... >>new technology and then depending on Marketing to convince the customers ... >>software developer responsibility. ...
    (comp.object)
  • Re: Just wondering... EvilOgre.com
    ... personally would love to see developers use my Encephalon components in their products and sell on EvilOgre.com. ... source from our personal source server if you plan to continue to sell and support the product elsewhere. ... I would like to be clearly distinguished as the original author, as long as your rebranding doesn't confuse the customers, I'm fine with it. ... When someone comes to see Encephalon components, ...
    (borland.public.delphi.non-technical)
  • Re: Programmer (or A Techinical person) in a Tester ...
    ... And then you report it ... And then if the bug happens again, boom - the developers have two ... Imagine the cook who just makes food or imagines his/her customers ... worse skills, nicht wahr? ...
    (comp.software.testing)
  • Re: NetworkManager update
    ... developers can get into the same mindset. ... I thought I did, having bought this lappy 3 weeks before the day I leave on this trip, but thats pretty much evaporated, rather silently it seems, now. ... The net result being that most pretty well know which side of a scrap I'll be rooting for, on those lists where I have been active for extended periods of time & that goes clear back to the coco list on Delphi in the 80's. ...
    (Fedora)
  • Re: Adding Customer Contact Emails to Address List
    ... customers aliases, so if they want to email only three or thirty at a time, ... the customer's email aliases are there. ... their own distribution lists if they want to.. ... Open the public folder and switch the view to "By ...
    (microsoft.public.windows.server.sbs)