Gunnar Kudrjavets

Paranoia is a virtue

Best practice - daily investigation of the test case failures

When it comes to the best development practices then daily build and Microsoft are practically synonyms. Not a big surprise. Jim McCarthy says it’s the heartbeat of the project. Steve McConnell covers it thoroughly in his books. Even Edward Yourdon thinks it’s worth mentioning. Etc. etc. To summarize: daily build is A Good Thing.

In software testing things are more complicated. What is the must use practice which everyone should follow, the process which is efficient and which gives everyone an honest overview of the project’s current state of quality? If you ask me then one best practice I would nominate is daily investigating all the test results. Sounds kind of trivial, doesn’t it? There’s nothing to this, you just look at all the test case failures every day and if there are bugs then you enter bug reports. Well, using the same logic the daily build is simple also - you just compile and link everything every single day ;-)

In real life investigating all the test case failures requires huge amount of discipline and noticeable amount of intellectual effort. Imagine thousands of test cases running on n different editions of your product. Every failure needs to be properly investigated and if applicable then bugs opened. Every single one of them. Every day. In our team we established a simple rule: you investigate all the test case failures before you start working on anything else. Sometimes investigation process takes ten minutes, but sometimes it takes the entire day. Sometimes ten test cases fail. Sometimes hundreds of test cases fail. Sometimes people aren’t happy about this and sometimes it even causes internal schedules to slip. But it’s worth every penny invested into this effort.

The end goal we’re trying to achieve is that every day we have a mapping table between failing test cases and relevant bugs. Every day we know which features and scenarios work and which don’t. We also know why, who owns fixing the bugs, and when they’re going to be approximately fixed. Simple but extremely useful practice to have.

Posted: Sep 20 2004, 09:54 PM by gunnarku | with 8 comment(s)
Filed under:

Comments

TrackBack said:

# September 21, 2004 5:53 AM

TrackBack said:

# September 22, 2004 1:43 AM

TrackBack said:

# September 22, 2004 3:10 AM

TrackBack said:

# September 22, 2004 3:11 AM

TrackBack said:

# October 1, 2004 5:01 AM

Stevan Zivanovic said:

Mybe I've missed the point here, but if the tester runs tests that are already defined and find faults, then by imposing a mechanism where the tester must enter at least on defect id to fail the test, you automatically get a link. Further, using a test management tool, you shoulod also be able to link a defect report to a test. This later feature is very useful to developers, who, if they have visibility of tests, can re-run the test without having to trouble the tester.

So to enable quicker nd more productive work, try imposing a system that forces a tester to record the defect against a tests. It makes management reviewing a lot site quicker.
# October 13, 2004 7:15 AM

Gunnar Kudrjavets [MSFT] said:

That's what we're doing, but IRL determining if certain test failure is a bug in product, bug in test case, some anomaly which is caused by the environment etc. isn't so easy and takes significant amount of time. Especially if we're talking about the server product where for example slight changes in the timing may cause some bugs to be non-reproducible.
# October 13, 2004 12:49 PM

buy hoodia said:

5d03eb05ac:55 Thank you

# January 16, 2008 7:46 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)