Monday, December 31, 2012

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.

Thursday, November 22, 2012


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!

Saturday, November 03, 2012

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!

Sunday, July 22, 2012

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!

Sunday, February 12, 2012

Unicorns, Fairies, and Squatches

Over the past few weeks I have seen numerous references to use cases accompanied by questions. 

Why do your tests not cover every use case? 
Why would you not test that?
Why do you test like that?

My inner ear rings with the thoughts of “Perfect Software” and “Complete Coverage”.

It is pretty easy to address the concept of perfect software by just handing someone Gerald Weinberg’s great book.  Let me quickly simplify the great message Mr. Weinberg presents in this book:  “THERE IS NO SUCH THING AS PERFECT SOFTWARE!”  Please accept my apologies for the cyber shouting.

Matt Heusser and Peter Walen did a great job at STP Conference in Dallas debunking the concept of “Complete Testing”, but you had to be there.  For everyone not in attendance of this wonderful and interact presentation let me quickly share the message:  “THERE IS NO SUCH THING AS COMPLETE TESTING!”

While I pondered why so many people still believe in unicorns, fairies, and squatches, I came to another conclusion.  Because of the belief in Unicorns, Fairies, and Squatches, testers realistically only get to actually test software 25% – 40% of their working hours.  The remainder of the time is spent chasing unicorns, fairies, and squatches.  I think this may factor in well with respect to another great book which I am still reading, "How to Reduce the Cost of Software Testing."  I need to calculate how much it costs to chase unicorns, fairies, and squatches.

I am so glad that with good testing technique in that limited testing time we typically find most critical defects.  I think it is truly OK to let the smaller fairies go.  Capturing the Squatches is the most important task at hand!

Do you believe in unicorns, fairies, and squatches?

Happy Testing!

Sunday, January 15, 2012

Is BDD a Mistake?

Sometimes life just gets in the way of blogging.  And sometimes I am not sure what topic to blog about.

Well I happen to spend some time this weekend reading all of the controversial posts on the Agile Austin forum.  The controversy was a multi-threaded monster.  However, the first post I read by Scott Bellware caught my attention.  Scott wrote a post about how BDD has essentially destroyed software development.

Here are a couple of excerpts.  And I am going to do my best to try not to take these excerpts out of context.

"You can't add quality to a product by adding tests."

Well I must say that I completed agree with that statement.  Tests serve as a net to potentially catch misses in quality, but in isolation a test does not inherently add quality.

"It also bears repeating that every automated test is a form of
coupling, and every coupling is an anchor chained around the neck of

So if I understand his point with this comment, Mr. Bellware is saying that implementing tests slow developers down.  I can see where that might be partially true; however, from my experiencing by writing tests developers think more thoroughly about the software they are building.  In the past three years as an automation engineer, I truly learned the power of TDD.  Writing test firsts showed key failures in my logic early.  I am not a developer, but I certainly saw a great advantage to writing tests against my code.

Here is a doozy.

"The problem - especially after so many years of degradation of the
Agile Development message - is that most coders are still driven by
the superstition that "quality" and "testing" are inseparable. This is
the software development world's Flat Earth superstition."

Definitely several points in this statement.  My main thought is that quality is the act of doing the absolute best work you can do in order to add value for someone.  I think doing your best should include testing, but they can be separate concerns.  Unfortunately I have not met many developers that ooze quality with every line of code they write.

"BDD is fascinating technology, and that's why it's popular. In and of
itself, BDD as a practice violates every design principle that

Wow!  Did he really say "BDD violates every design principle that matters."  I admit that I am not fully versed on principles of design, but Wow!

 I tried introducing Cucumber as a test automation practice.  What I loved about BDD, Cucumber, is that it started a dialogue around what value a feature provides.  I also liked the fact that it was extremely easy to take text and instantly turn it into a failing test.  What I did not realize was how hard it would be to get people on board with Cucumber.  

"Quality Built-In is how quality is created. It's a matter
of designing the right thing and not making mistakes."

So I guess as a tester I think this is a "Flat Earth superstition".  Fundamentally I disagree with this statement, because the unfortunate truth is EVERYBODY makes MISTAKES.

"BDD - in the Cucumber/Gherkin/GWT sense - is knowable as a mistake.
It's a mistake from a methodological perspective. It's a mistake from
a process perspective. It's a mistake from a usability perspective.
It's a mistake from a structural design perspective. And it's a
mistake from a team and organization perspective. That we don't see
these mistakes is a testament to the immaturity of our industry and
the perpetual susceptibility of its participants to unfortunate
fashion trends."

Again Wow!  Scott is saying that BDD has zero value.  I am going to respectfully disagree.  I will agree that it is a huge struggle to figure out the most efficient process for using BDD.  I have certainly made mistakes.  And I would admittedly state that I have not fully studied the idiosyncrasies of BDD.  I believe as a tester and automation engineer, Cucumber helps us find where quality was NOT built in.

"It's heart-breaking (as are many missed opportunities in software
development) to see the extent of harm wrought by BDD in the general
programmer population. It's heart-breaking to see that programmers
still have very little interest in the meaning of quality and it's
fantastic potential for massive increases in productivity."

So to me the above statements gets to the heart of Scott's forum post and the underlying concern really has nothing to do with BDD.  "Very little interest in the meaning of quality" is the most telling part of the above statement.  I know that in their hearts software developers care about quality, but I think there are many other influences besides BDD that impact quality.  The hard core fact is that mistakes are made.

Here are a couple of links to more material to support Scott's premise,  Oslo presentation and a Lonestar Ruby Conference.  These presentations provoke additional thought.

I will conclude by stating that Scott really sparked my two brain cells to work over time.  Was introducing BDD a mistake?  I still do not think so.  Did I make mistakes with respect to process and my personal education on BDD?  Yes!

I doubt Scott Bellware will ever read this post, but I must thank him for truly making me think.  And I think there is so much more to learn with respect to quality.  I plan to pay more attention to see if BDD is truly a mistake.