Sunday, February 6, 2011

on discovering bugs late

It’s been a while since the last update. Busy testing for the final regression of our product. Or is it?

Regression test is defined as the tests where we want to see if any fixes or changes in the codes, meant for fixing certain features, do not interfere or break other unrelated features. The nature is a repetitive task all over again. Which best to be automated. Or is it?

The fallacy of saying certain phase of test is a regression test, more often than not, is not a regression at all. Time spent is for validating the bug fixes. Or discovering new bugs which may be caused by the fixes or exist even before the fix is introduced. Anyhow, the objective strays from its original path. Regression is now just another round of tests. Or is it?

So, who’s at fault? Developers? Testers? Maybe, nobody at all. The time factor plays a big role in deciding whether a regression test is really a regression test. Like usual cycle, the bugs are discovered late and the fixes come in late, so the testing occurs late.

“Blame the tester then, for discovering the bugs late. They should have discover them earlier and save our times!” Yes and No. How do we know whether the bugs can be discovered earlier? How do we know that the bugs are not recently introduced?

I recalled my previous company, where a post-mortem is conducted to see whether the testers are discovering the bugs late? (Can you believe that resources are spent to discover whose faults are those, instead of finding more bugs? Well, in a mud-slinging situation where everybody is trying to save their own asses, anything is possible. :] ) We actually asked to re-test some late-discovered bugs in the earlier releases, just to prove that the bugs can be discovered earlier! Isk isk isk…*shaking head in disbelief*

So, what? If it’s tester fault, we’ll gonna blame the tester then? Or if the bugs not there, we gonna blame the developers? Knee-jerk and reactive decisions like these won’t bring any real benefit I think.

One thing we can do to mediate this, is to try discovering the bugs earlier. How? Strategize on critical features, or features known to be prone to bugs. Or new features where they aren’t enough testings are done. Or features that are not tested that often (imagine them as the uncharted territories). Do an impact analysis on each fixes coming in, test again features that are related to that fixes.

Which one is a better approach: Regression after regressions, or specific target risk-based tests? What say you?


No comments:

Post a Comment