Category Archives: Leadership

Technical and personnel leadership

Inventory-taking

Recently I sat down and asked our bug database about my last four years of being a software tester. Here are some statistics I found in it:

Bug counts

Bug stateCount
New12
Assigned5
Reopened3
Fixed251
Invalid33
Duplicate27
WorksForMe14
Reminder1
Won’t Fix16
Later2
Sum364

This makes 91 bugs per year, or 1.75 per week. 68.96% of the bugs I opened got fixed, 9.07& are invalid, 7.42% are duplicated, 4.4% will not be fixed, 3.85% could not be reproduced, while nearly 5% of the bugs I opened are still either new, someone works at them or they needed to be reopened.

What does this tell you about me as a tester? Am I a good tester? A bad one? A mediocre? Were my bug reports always clear? Did they motivate the responsible developer to fix them? How did the bad reports distribute over the years?

Now, these are the more interesting questions to ask in order to make any sense on whether I am a good tester or not. Mere bug counts or percentage values do not reveal anything about this. So, rather than managing by the numbers, maybe manage by working with the individuals. The famous paper on software engineering metrics from Kaner and Bond has more on this.

The Deliberate Tester – Episode 3

The Software Testing Club put up the latest episode from my little testing fable called The Deliberate Tester.

After Peter got introduced to session-based Exploratory Testing in the first episode, he got introduced into software test automation in the second episode. Now, in the third episode Peter is faced with the trade-off between the two.

For the next episodes I started to give Peter a first test challenge that he shall conduct. I am really looking forward on this one.

Software Craftsmanship week: Deliberate Practice and Learning

Reflecting over the history of the Manifesto for Software Craftsmanship and the ideas we concluded for the The Software Craftsman’s Ethic, so far I just covered two aspects. The key ideas behind the manifesto and the ethic statements is that craftsman care for their work, taking pride in it, they practice their craft regularly, they learn deliberately, and finally they share their knowledge in communities and with peers. So far, we have started our journey this week with on the sharing part, and continued to take a closer look on the caring part in the last two days. Today, we will spent time on deliberate practice and learning parts.

Continue reading Software Craftsmanship week: Deliberate Practice and Learning

Software Craftsmanship week: Clean Tests

To some degree I envy programmers for their clear guidelines. One of these set of these guidelines is well-written in Robert Martin’s book Clean Code – A Handbook of Agile Software Craftsmanship. (Personally, I hope that Kurt Häusler will review it this Software Craftsmanship week on his blog.) So, today I decided to write about Clean Tests, and what a book on the topic should cover.

Continue reading Software Craftsmanship week: Clean Tests

The challenge of the Nine Smurfs

On Monday, I issued a little challenge on a smurf house we got as a wedding gift. The challenge resulted in eight comments overall, and I was struggling to clarify my initial observation. To make things short, I learned something from the comments. What I initially observed was, that the Brainy Smurf was reading in front of a flower, while Smurfette carried a watering pot in front of a pile of books on the first floor on the left. From the comments on my blog I learned, that I should have taken the hindsight, and do some more follow-up testing. The variety of similar mistakes in the arrangement of the smurfs was fabulous.

That said, when going through the comments, I need to find a way to rank the responses I got. A simple second-order measurement could be the number of comments per individual. In this category, Jeroen Rosink is the clear winner. He left two comments. This does not say anything regarding the quality of the comments, of course. So, I needed to find a different rating scheme.

So, on the contextual things remarked, I even didn’t get a hint, why Painter Smurf is in front of the cake, why Handy Smurf is trying to fix the gift in front of him, why Chef Smurf wants to taste the blue paint, or what any of the other smurfs do there.

Regarding the building, the inconsistencies in the building itself and the weather outside are great things to notice. In addition the arrangement of the Smurfs with regards to the background could be a point. Why is Papa Smurf working in that distance to his table? Why does the Fisher Smurf fish the pillow from the Sleepy? Where are the stairs to the first floor? Where is the chimney outside? Well, if you would be able to look on the back of the house (a mushroom) and get a 3d impression, you could see that the walls on the first floor are less in depth than on the ground. So, the chimney could go out of the mushroom house outside, but on the back of the house no indication of any chimney are present. The comment from ElizaF was also very well put. The structure of the building is not well architectured, as there is no kitchen, and no toilets. Maybe Smurfs don’t need them.

Finally, the answer I liked best came from Anne-Marie Charrett, and I was tempted to state that it’s a pure example of the English humor, but recognizing that she’s from Ireland, I realized that I should refuse.

I dunno, if you live in a world where its ok to have blue skin, anything could be acceptable. :)

Well said, Anne-Marie.

Last, but not least, here are some things I missed. I didn’t see anyone trying to find references on the Smurfs and the particular campaign run by a German producer. Before putting up the challenge, I needed to verify that our Smurfs weren’t just misaligned. Thereby I found a picture of the arrangements as well as a selling offer for the diorama. For this write-up I used the list of Smurfs from wikipedia. The plug Milk, minus Kakao is part of the brand Kinder Überraschung, indicating that these sweet chocolate eggs are some kind of healthy. Overall this is very great domain knowledge, which could have helped in the decision on “problem or not a problem?”

Physical and mental evolution

Human evolution brought up some clever ideas how to survive in the wild. From my courses on becoming a swimming trainer, I know some parts of the physiological aspects in play when you exercise your body. While reading through Pragmatic Thinking and Learning from Andy Hunt, I was amazed that evolution build up the same concepts inside the brain. Here is my summary on it.

Continue reading Physical and mental evolution

The Second System Effect in Software Test Automation

Matt Heusser blogged today on generating new ideas. In his entry, he cites from Weinberg’s Becoming a Technical Leader. Weinberg lists up the three obstacles to innovation – one of the three parts of his leadership model. The three obstacles to innovation are self-blindness, the No-Problem syndrome, and the single-solution belief. Continuing he explains the three keys to innovation based on this: Learn from your errors, learn from others, and copulate together two great ideas to form an even greater idea. Matt also mentions my struggle to find an article where a great software test automation framework became shelfware just because it couldn’t stand the technical challenge – or maybe just the human aspect of it? So far, we just found opinions on software test automation projects having failed, but no real hard data.

So, to overcome this lack of available material, let me write about my experience with software test automation, the problems we had, and how we overcame them. Thereby, I will not only enable myself to learn from my own errors, but also provide a system you may copy yourself, or which you might combine with another great idea that you have established in your company. In fact, most of this shouldn’t surprise you. During the last year, I also presented our approach on a test conference – here‘s the paper I wrote on this.

Continue reading The Second System Effect in Software Test Automation

Software Management 0.5

Just this morning, it appeared to me, and there the solution was to all our problems. It had been there, so directly in front of my face, that I haven’t seen it, but it is so clear now.

We need to separate testing from the act of programming.

Wow. That’s a statement. But I’m serious. It has never worked and the large amounts of failing teams with Scram or Krumban, or whatever they call it, got it wrong. Yeah, Agile got it wrong. Collaboration is for the weak. After having spent over fifteen years with this crap, we need to get our bricks for the silos out from the closet again, and build up walls between those teams. Give testers different offices, on different floors, in different buildings, heck, what am I saying, give them different planets to be on, so they communicate mainly over the bug tracking system.

And I want to see a test plan, with every written detailed test up-front. Now. Show me. And I want to see Gantt chart based progress report, every week, and every day or even twice a day if there is an escalation. And I don’t want to spent time on re-planning. The initial plan must hold. Test design documents are fixed after being created initially. Yeah, that’s what we’re going to do.

While we’re at it, is there a way to get that waterfall model more heavy? How much celebration may we add to it? Just that? Come on, give me more than just the usual bug metrics and that crap. I want three additional testing cycles in the end. And I want QA to approve every delivery we make. Sure, they have to sign it. On paper, three copies to each major division head. Exactly.

If you haven’t figured yet, this is a rant about a personal Black Swan that a friend of mine just told me about his replaced management. Exactly, they’re separating the collaboration between programmers and testers, dividing them, right now, in this century, nearly ten years after the Agile manifesto and it’s focus on team-values, and cross-functional teams. This manager made the experience that developers and testers agree upon a delivery in a dysfunctional way. Therefore he wants to separate them again. And every major change project is failed if it is not implemented after 90 days. I’m not that good as a clairvoyance, so, what would you suggest my friend to do next?

Testing and Management mistakes: Causes

So far, we have taken a look on how to give the right response to common management mistakes. Today, I would like to take a closer look on the underlying problems that make a test manager react to management mistakes in an inappropriate way. By re-iterating over the dialogue of our manager Magnus and our tester Tim again, we’ll try to guess what the initial reaction could have caused, and therefore seek out for opportunities on how to solve the process problem.

Here are the links to the prequel of this blog entry:

Continue reading Testing and Management mistakes: Causes