Serenity Clock and the Lost Defects of Doom

Our Quality Assurance Engineers have been integrated into our Scrum teams now for over a year.

For the most part, this integration has improved quality by leaps and bounds, but like others learning the ways of Scrum, our QA Team admitted just this week to still harboring a few die-hard habits and fears.

In a Scrum world, a meeting of retrospective follows the end of every sprint, and in that meeting, all problems and mistakes are identified and potential avenues for improvement are explored.

Eventually, through this incremental process improvement cycle, both process and product become more refined.

The one thing you don't do is to try and solve problems before they are proven to exist. Unfortunately, this way of thinking is completely counter to the historic QA mindset.

That traditional mindset reminds me of Indiana Jones.

Indy tackles a problem head-on, expecting the worse, and improvising as he is attacked. When sent into a cave to retrieve some artifact, he knows he must explore every tunnel, even if he knows exactly which cavern holds the item. If he doesn't do this, some giant boulder or tribe of cannibals may come out of that tunnel and the movie will end early.

Our QA team—Dave Blanton and Serenity Clock—dream of similar adventures.

When they are sent into the dark and frightening realm of defect verification, Dave and Serenity feel they cannot simply verify the defect and get out. If they don't explore each and every corridor, some incompetent developer will kill one defect and give birth to three. Those new defects will then scurry and hide in the bowels of our C# code, only to appear later and make QA personnel look like brainless monkeys.

Exploratory Testing is  a staple of testing new code, and it has a home in the Regression Test arena, but it has no place in the Defect Verification process.

"I take pride in our product," argues Serenity Clock. "I must explore any chance I get."

"If we don't," adds Dave Blanton, "We will be embarrassed and ridiculed for not doing our jobs."

Maybe this happens in some other world, but not in the universe of Scrum.

Mistakes happen. Identify them. Fix them. Put measures in place to prevent reoccurrence.

Then, move on.

Blame no one—otherwise everyone will be afraid to admit mistakes and all problems will take longer to solve.

Command, control, and punish are yesterday's mistakes. Trust and transparency are the secrets of today's management successes.

Remember when Indy was up against that master swordsman. In the days of Errol Flynn or James Bond, he would have picked up a sword and matched the duelist blow by blow, until the evil doer was defeated.

Indy pulled out his pistol and shot the guy!

The old ways are dead. Embrace the new if you want to experience success.