The Five Why's and Testing Software

re: The Five Why's and Testing Software

jdan — Sat, 18 Oct 2008 00:34:50 GMT

the 5 whys are part of the whole kaizen practice. I am always slightly amused and dismayed that they got the Idea from the Americans( like Deming) and used it to displace America in Manufacturing.

I'm not much of a coder but I'm interested in seeing how you apply this to coding.

VSTS Links - 10/20/2008

Team System News — Mon, 20 Oct 2008 17:11:33 GMT

Grant Holliday on What's the difference between tf workspace /delete and tf workspaces /remove? Shai...

re: The Five Why's and Testing Software

Neil C. Obremski — Wed, 22 Oct 2008 18:27:13 GMT

This is why the Terminator was so effective ...

J.C. - "You can't just go around killing people?"

Term - "Why?"

J.C. - "You just can't!"

Term - "Why?"

J.C. - "You just can't, alright!? Trust me on this."

Term - *stare*

Hmm, maybe he didn't get enough why's in.

re: The Five Why's and Testing Software

Director — Sat, 25 Oct 2008 02:50:35 GMT

You know, kids do this automatically. What I found out was that if I kept actually answering instead of cutting it off with "Because I said so" that I found that sometimes I really didn't have a good answer.

I decided at that point to (try to) always have a very good, justifiable reason before asking my kids to do things. If I couldn't explain it then I shouldn't be asking.

re: The Five Why's and Testing Software

Kujo — Mon, 27 Oct 2008 19:25:09 GMT

I read (in a book somewhere) a nice extension of "the five whys": Any failure of a (reasonably complex) application is usually at least two bugs.

- The program crashed because it didn't handle a NULL data field

- The program would fail to initialize the data field when reading an old version of the record

- The periodic maintenance procedure fails to update records with non-unique account names

- etc.

This is a little more interesting than just drilling through 'why's because each of these answers is itself a bug that needs to be tracked and fixed. However, as soon as any one of them is fixed, the crash will stop. I sometimes think that half of our code is the correct handling of the "impossible".

"We rarely--if ever--ask." Do you just mean from the testing side? To me, that's a mandatory part of making a fix. I certainly always ask during a code review of such a change.