The First Person to add to Your Team?

While you'll have to work on the people, tools, and processes tracks simultaneously, we'll take them one at a time in our discussions.

Let's think about the people that you need for your team first. A while ago, I wrote an essay for IBM Developerworks [1] that described some of the characteristics (and some of the characters) that you should look for in software QE engineers in order to build an effective team. I'll expand on some of the ideas from this essay in a later post. The specific subject that I want to address in this post however, concerns the first person that you should try to add to you new team.

The first person that you need to look for is a "grinder."

OK. What's a grinder? And, why do you need one first? Shouldn't the first member of the team be a test framework architect or automation coder? Think back to our hypothetical project situation. You have to juggle the creation of the team, its tools and the project's set of QE processes while you also ship a product. The skill set of the first person on your team has to be that of a general practitioner (sort of a software Swiss Army knife) who can both execute and build tests. But beyond his/her technical skills, you also need to find someone with the right attitude.

Once again - what's a grinder?

It's a sports metaphor. It's sometimes applied to baseball pitchers, but it most frequently is used when describing golfers. In golf terminology, "grinder" describes someone who is faced with adverse conditions and is not playing their best game, but is still able to, through effort and determination, "grind" out a victory. A great example of this happened at last month's US Open. [2] Tiger Woods was playing in his first event after knee surgery. As it turns out. he came back from the surgery before his knee was fully healed and as the tournament proceeded, he was playing in more and more pain. For me, the image of what it means to "grind" was watching Woods experimenting with different swings and shot patterns as he searched for a way to swing without collapsing in pain. In spite of the pain and the difficulty of playing the most difficult course of the entire season, he was able to focus on his goal.

You'll need the first person on your team to have this type of attitude. (You'll also need to be something of a grinder too.) If your first team member is a test architect, he or she may become frustrated by the need to meet short-term product delivery goals instead of being able to concentrate on a longer-term design effort. Likewise, if your first team member is a test automation specialist, he/she may become frustrated by the need to "jump in" and perform manual or exploratory tests. [3]

So - start with a general practitioner, but be sure to find one who can "grind it out."

References:

[1] http://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/dimaggio

[2] http://www.usopen.com/en_US/index.html

[3] http://swqetesting.blogspot.com/2007/11/in-praise-of-exploratory-testing.html

Three Tracks

I was wandering around FUDCon[1] in Boston a couple of weeks ago, and ran into someone who said, "I really like your blog, but the entries have been very short recently."

Ouch.

The awkward thing was that he was correct. I had been unable to contribute much to the blog for a while as I had been concentrating my writing time on Red Hat Magazine[2].

Let's get back to our "now what do I do?" thread. In the last post, we talked about dealing with risk including understanding that risks are always present. OK, you know that your new friend and constant companion is Mr. Risk. Now what do you do?

You have to make progress on (3) tracks:

* People
* Tools
* Processes

We'll examine aspects of each of these tracks in the coming posts to this blog.

References:

[1] http://fedoraproject.org/wiki/FUDCon/FUDConF10

[2] http://www.redhatmagazine.com