Yet another round with defect Severity and Priority

Let me start by a quote from a developer.  “We only focus on priority.”

I have had so many conversations around severity and priority.  Rather than banter about the difference and the usages, I came up with a new concept relative to defects.

Equality to all defects!

I would like to see teams implement TDD practices and a mantra of “We found it. We will fix it!”  Imagine a world where developers, testers, and product managers all treat every defect equally.   We cannot release new code because it is defective.

In the Agile development world the best teams fix their defects as they build the product.  Testers are catching them early in the process, so why not fix them.  It is true that there is no such thing as perfect software; however, if you happen to find an imperfection should you ignore it.  The answer is no.

Do you ever hear “We are do busy to fix defects”?  Or  “that is just cosmetic, so we will fix it later”?  The statements indicate that defects are not important. 

All defects should be treated with equal importance no matter where they are found.  In fact if a customer finds a defect it should take on greater importance.  The defect should be fixed immediately in the next sprint.  If the team uses Kanban then push the defect to the top of the queue.

If we treated all defects as equals then we can throw out severity and priority.  Most importantly we testers no longer have to explain that there is truly a difference.

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?

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!

Lister's Law

I am not making any resolutions to blog more although I should, but I am ending 2012 reading a very enlightening book called Slack by Tom DeMarco.

I am probably a third of the way through the book.  On page 50 there is the mention of something referred to as Lister's Law.

"People under time pressure do not think faster." - Tim Lister

When I read that it had a familiar ring.  Perhaps Michael Bolton and James Bach have echoed similar phrases.  I know these two pioneers encourage us testers to think.  In fact there actions challenge us to think.  I never stopped to consider that thinking happens at a fixed rate.  I have never actively set aside time to think nor have I pondered the rate of thought.

I do not know about other testers, but I do not think my brain every stops.  I actually believe that is why I have trouble sleeping, but that is another story altogether.

Despite the wisdom in this book I feel testers are always going to face an extreme amount of pressure.  Under the burden of pressure and rapid decisions how can we afford the time to think.  I do not yet know how this concept of a fixed rate of thinking will influence my day to day actions.  But I do know that I need to strive for a balance and inject some slack into my day for deep and explicit thought.

I am a reactionary type of person and very free to offer opinions.  Many time my opinions land me in trouble especially when I do not take the time to think about the context of my points and the perspectives of the audience.

A colleague the other night joined me at a concert and we were talking about the open mouth insert foot phenomenon.  He stated he now considers three things:

• Should what I am thinking be said
• Should it be said now, and
• Should it be said by me

I really think he is spot on.  We especially need to give ourselves the time to think if we get to the third bullet in this thought process.

I am not sure about all testers, but I feel constantly under pressure.  In 2013, I am going to try and find ways to relieve some of that pressure.  I do not know how yet, but I assure you I will be giving it some more thought.

Slack is written with a business focus, but I believe the lessons expand to our society.  We simply put to much pressure on ourselves and those around us.  

Add some slack to your day to day operations and add Slack to your 2013 must read list.

Appreciations

Here it is Thanksgiving morning 2012.  Of course I woke up at 5:00 AM when I had an opportunity to sleep in.  I meandered through all of my RSS feeds.  And of course I stumbled upon this gem of a post by Christopher Avery.  By the way Mr. Avery is an awesome person to chat with.  I had the absolute pleasure of talking with him at the Rally On conference this year.

On Friday November 16 I attended Keep Austin Agile Conference put together by Agile Austin.  I learned quite a few things at this conference, but there was one thing I had not heard before regarding retrospectives.  Earl Everett in his talk on "Retrospective Tips, Tricks, and Traps" he mentioned the use of appreciations during retrospectives.

Honestly I think it is a great idea.  What I immediately struggled with is how many appreciations or the quality of the appreciations.  Also I had some thoughts on the emotions of appreciations.  I concluded that I do not show my appreciation enough, so I will incorporate appreciations more into my daily routine both at work and at home.

Christopher Avery added more controversy to my thought process by stating "Reflect on your ratio of potential vs. actual acknowledgment".  I completely agree that each day we should reflect and I need to add a list of appreciations to that reflection, but how many of your appreciations should truly be acknowledged.  I have been thinking all morning as to what ratio would be good for me.  I keep thinking my ratio of actual appreciations should be low and strategically delivered.  I am leaning toward attempting to do something like take action on my top two appreciations for each day regardless of how many potential appreciations I can come up with.  Is that enough appreciations?  Maybe not, but it is certainly a start.

Another thought I have is that in my list of potential appreciations there may be reoccurring recipients.  Perhaps one of my daily appreciations should be directed toward someone or something new on my list each day.  I kind of see this as a twist on "Paying it Forward", but it is absolutely practical to show daily appreciations.

I am a facilitator of meetings.  As a facilitator I easily fall into the trap of speaking to much.  People who know me, know I have an opinion on everything.  I am hoping by limiting my appreciations to two per day, appreciations will become contagious.  In a collaborative agile software world we could all use a bit more appreciation.

It is Thanksgiving after all, so I have certainly a great deal to be thankful for.  On Monday show your appreciations to your colleagues, especially a Tester.

Happy Turkey Day!

Time to think

I truly dislike the fact that I do not blog more.  I still do a lot of reading and I am participating what seems to be a great course on-line with Stanford University called "A Crash Course on Creativity".  I simply do not do enough writing.

This morning I read Michael Bolton's blog post.   As usual his post got me thinking on various topics but primarily on "Where does my time go"?

As Mr. Bolton describes I am going to go through the exercise of using graph paper to illustrate where my time disappears to, but more importantly I am going to think more clearly as to where my time should be spent as a Senior QA Engineering Manager.

I need to spend more time marketing the value of testing.

I need to spend more time marketing test innovations.

I need to spend more time on educating and mentoring the team.

I need to spend more time educating myself.

I need to spend more time learning to become a forward thinker or visionary.

Ideally I would like to spend more time testing, but apparently that is no longer in my job description as a Senior Manager.

So just in this very short blog post of thinking out loud.  I have come up with two key areas that I must find time for, Marketing and Education.

Hmmm!  Now I need to go spend time thinking more about why do I have to market testing at all and why I feel compelled to educate others or myself.

First I guess I need to steal some graph paper from our daughter and map out where my time goes.  Then I might be able to add a slot for additional blog posts.

Happy Testing!

Focus on the Customer

Hello Testers!  It has been way to long since I posted something on this blog.  I find it interesting that it took a vacation to inspire me to post again.

While planning the vacation I visited numerous websites.  As a tester, I was somewhat  alarmed how many defects I observed on these websites.  The defects did not really bother me too much because they are websites.  What really bothered me was how non-userfriendly many of these sites are.

When booking airfare it was unclear as to whether the prices were round trip or each way.  When booking trains it was not easy to determine was it a direct route or a slow route.  Key attributes such as family passes were not obvious nor routinely recommended.  You purchase your ticket for Virgin trains, but you never ride on a Virgin train.

The craziest thing I found wrong with almost every website is that it was not obvious how to contact customer support.  Many times through exhaustive searching of a website I could not find the answers to my questions.

So here is the one example that set me over the edge.  Our daughter has become a vegetarian, so she wanted me to contact United Airlines to make sure she got the vegetarian meal on the plane.  I thought this would be a simple radio button or checkbox on the user profile.  Hell, we had to add passport details and other personal information.  When I went in to adjust her profile I could not find anywhere to change her meal selection.  I finally ended up calling customer support.

When we were preparing to leave my daughter asked me to confirm that she had a vegetarian option for the trip home.  Again nothing on the website was obvious.  The only number available to call customer support was a 1-800 number.  No where on the site could I find out an efficient way to contact customer service from an international location.  They flew us to a foreign country, so they should be prepared to service, me, the CUSTOMER.  Well, calling from London on a cell phone, I incurred phone charges at an international rate.  I have not got the bill yet, but I can just imagine the cost of this inquiry.  As it turned out they set the vegetarian option for the entire round trip flight, but how was I to know.

I will not even get started on my experience with airport kiosks.

Bottom line for me as a tester is that I need to pay extremely close attention to what the customer should experience.  I need to focus on not only the functionality that is on the web page, but what functionality simply might be missing.

Be the USER!