Here’s a simple metric for you: keep the number of open bug reports on zero.

Simple, eh? A yes or no – a completely binary metric. How wonderful.

After several projects that turned ugly after some time, because the number of open bug reports just rocketed to the sky I saw some general trends… general from those projects, of course, but maybe you can add your observations as comments to this blogpost so we can get some better, ahem, metrics on this.

I have some questions for you testers out there who like using test cases. To be clear, I’m talking about detailed, stepwise instructions written in order to guide testing and be executed manually.

I have never enjoyed using them and I want to know why you do. Really. I don’t get why test cases are ‘all that’. If there’s anyone out there that loves using test cases, please clue me in as to why. I don’t get it. Help me understand.

If you ever tried SBTM (and if you haven’t – do try it), you might have had the sensation I often get during debriefs: “oooohhh!! I should also have tested this … and that! and…”

Even after nearly two hours of concentrated testing, all that is needed to get more inspiration is to tell others what you did – after a little recess.

I think I will call this iterative thinking, in case no-one else coughed up a name for it – or even that name for it

It shows up often during debriefs, that are almost put on hold while a few testers grab the nearest computer to show, tell and discuss – actually sometimes restarting a session to refine the information they’ve got.

I don’t think we value iterative thinking enough. We tend to value just the ideas we had. I think it would be valuable to allow ourselves to re-invent our ideas, though many would see this as a waste of time. “No need to do that, we already got the ideas we need”. But maybe we can still improve things, and get even better ideas once we revisit the chain of thoughts that led us to the first idea. By that time we will have learned the first idea, so it’s not really new.

All it would take is to allow for recesses and repetitive meetings, when we’re to come up with new ideas, analyze stuff, get inspiration. Exchange the outcome from the first, short meeting with others. Take whatever inspiration to the next meeting, which is held somewhere else. Move around, play with the idea. Refine it.

Would that be so hard?

Rummaging through some documents on my laptops the other day, I accidentally stumbled over an old presentation made by a “process consultant” who shall remain nameless for his own sake. I hadn’t paid much attention to it before, but I opened it and read the executive summary just for fun and got a bit scared of what I read. Here are a few of the friendly suggestions in a nutshell for you to consider.

1. Don’t spend time developing your own processes, “steal” standard processes and use standard solutions.

Yeah, imagine what would happen if you left it up to the people working in the organization to exercise judgment and responsibility over how work should be structured. Or if you were to involve them in the change process.

I like being corrected when it improves my performance or keeps me from looking silly in public, but it still grates a little. There are people in our community who like to practice using words very precisely and I think this is a good impulse, but I find it too easy to fall into abstract semantic arguments. As such, I’m a little burnt out on the topic.

Yet, when I run across a post Alan Page put up, which mentions a post by Matt Heusser, where they grapple with “test strategy“, “test plan“, “test design” I find I do have some energy to put towards the topic.

For things to change, you have to change. For things to get better, you have to get better.

-Jim Rohn

And this is the hard part. Fine, I’ll write some unit tests. Sure I’ll fill out my sprint tasks and track progress. I’ll be present at the standup and talk when it is my turn.

I won’t change or get better though. You can’t make me. And you don’t really want to. Otherwise we wouldn’t still be getting the same results – missing each sprint goal time and again.

Software Config Management has been, in my experience, one of those nebulous practices that defies definition until you realize that you need it. It’s probably something you can get away without having if your setup is small enough and your developers, testers and system technomancers all communicate clearly, effectively and frequently (I’ll just wait for the snickering up the back to subside, shall I?). Dedicated config management personnel seem to happen to a company when it reaches a certain size of personnel rather than a certain system complexity. I sometimes wonder if that isn’t a bit like shutting the proverbial gate as hoofbeats fade into the distance.

According to Schwaber, the Old Guard commented on the invention of Scrum by saying it was great if, and only if, the team

• Was staffed with outstanding engineers
• Had excellent tools available to them
• Had engineering practices down pat
• Understood the business and technical domain inside and out
• Were not interrupted
• Had all the resources they needed

If this was the case you could use Scrum successfully.