Sunday, January 27, 2013

What work is left is harder!

I am reading Slack by Tom DeMarco.  There is a chapter where he is talking about process obsession.  I have always been against process for the sake of process.  At one of my previous jobs it took at least 8 hours a day just to get through the CCMI daily bull shit.  My point is not to rant about how inefficient institutionalized process is, but to share a quote from the book.  I found this statement interesting.

"When the new automation is in place, there is less total work to be done by the human worker, but work is left is harder."

As an experienced tester I believe test automation is important.  I promote automation so that we have more time for cognitive testing.  I cherish the time available to execute well designed test sessions.  What never occurred to me is that the cognitive testing just might be harder than the automation.

From my experience automation is pretty darn hard.  Once I completed automation I did feel a great sense of satisfaction, but I never pondered that I had freed up some of my time to do stuff that was harder.  I viewed automation as giving me freedom.  I now had the freedom not to do scripted testing, but the confidence to explore.

The phrase "less total work" is also interesting and from my point of view somewhat misleading.  In theory the more software automation you have the more time you have to innovate new concepts and ideas, so in essence the scope of work increases.  With more automation I believe that maintenance increases.  Automation frameworks are constantly advising as a technology.  At some point the team must refactor to stay current.

I am looking forward to the day when automation equals less work!  For some reason I think I am going to be waiting a very long time.  Does software automation truly give us slack?

Sunday, January 06, 2013

Vanishing Defects

I know I watch to much television, but the Allstate commercial during the Seahawk versus Redskin game gave me an idea.  Allstate has a concept called the vanishing deductible for safe drivers.  Can we use a similar idea with defects?

I would like to propose that if a defect is more than 120 days old without a resolution, we should make it vanish, Vanishing Defects.

Development teams typically are investing the majority of their energy building new features.  From my 12 years of experience there is little time dedicated to fixing the defects.  The problem is compounded deeper by a defect ranking system.  If severity of defects is marked annoyance, cosmetic or non-essential, defects become destined for the eternal defect pile.  Teams triage defects and set a priority.  If defect priority is marked normal or perhaps some day, then those defects are also destined for the eternal defect pile.  The vanishing defect model would automatically reduce the size of the defect pile.

When customer support inquires about a defect that is older than 120 days, the response would be simple.  Your defect vanished!

Some software development teams should be on the A&E TV show, Hoarders.  I have seen backlogs with defects greater than 2 years old.  Should defects be hoarded?  With the vanishing defect policy intervention would not be required.

Ok!  I will make a compromise. Instead of vanishing defects perhaps the defects should be archived after 120 days.  

I think a better model to consider would be Defect Regeneration.  This would be similar to a gecko growing a new tail.  All defects must be fixed within 120 days.   Some geckos regenerate a tail in 2 days to 2 months, so 120 days should be plenty of time.

That concept will probably not fly either, so we are destined to see the giant landfill of defects forever!