Sirius Ruminations

Over the last few months, I have had the opportunity to review a lot of paperwork for a few clients, most of it being test plans. I hate paperwork; not that paperwork, or test plans themselves, are inherently evil. It is just that in about 90% of the cases I have experienced, they are largely used as an excuse for, or at best a substitute for, doing any real work.

For the last four years, I have been working with a very large government organization on a variety of testing projects.  This experience has changed much of the way I look at and think about testing.

This morning, I am sitting here writing a blog about tool blindness.

I am writing this blog, because I have the time to do it.

I have the time to do it, because my test environment is down.

I recently went to a conference, my favorite, StarEast.  For many reasons, I have been laying low this year, so for the first time in many years, we did not participate in the vendor expo, and I did not submit a presentation.  I was simply an attendee.  However, since we have been so heavily involved for so many years, when I checked in I was pleasantly surprised to receive a small gift for being an alumnus, an insulated coffee mug with this years conference logo on it.

As months go, this has been a tough one.

As weeks go, this has been a good one.

I have, for quite some time now, been involved with a very large client who is creating a massive SOA system.  Concurrently, the organization is moving from being very decentralized, to being much more centralized.  The two are not unrelated – this kind of project requires massive amounts of coordination that the organization previously did not support.  Growing pains abound.

Last week, I was driving around, and my 7 year old daughter was in the back seat with me.  We were chatting as we drove along (her mind tends to wander and bounce around) when she suddenly made some comment about something she had observed.  I was immediately struck with the depth of insight her comment carried with it, and thought to myself, “Oh, I must write a blog about that – that is so relevant to what we do!”

A few weeks ago, at StarEast, I was talking with Antony Marcano and Rob Sabourin about agile processes, and asked a question that has become a perrennial favorite; Can you be agile if you are not creating and executing loads of automated unit tests?

Few things in life are certain, and in software testing, even fewer.  Like our modern political system, the community of software testers is fractured and splintered.  And while we may draw bold lines around big camps such as Context Driven or Factory, Manual or Automated, Exploratory or Scripted, within any of those major camps there is fierce competition.  This can leave us poor individual testers wondering if there is in fact nothing solid for us to hold onto.  But there is… 

Recently, three unrelated events have given birth to a new idea in my head, and I wanted to share it with you. So, to properly set up the background, the three unrelated events:  At the recent CAST, James Bach presented a keynote, “Against Certification”. During that presentation, one of the things he did was to review some of the “Body of Knowledge” documentation upon which such certifications were based. As he reviewed this documentation, one of the things I was struck by was an underlying pattern of motive driving much of the documentation. That motive was the ability to predict, manage, and control the SDLC. Much of this “Body of Knowledge” for test certification was obviously written by managers, not testers.

The right tool, for the right job, at the right time