Is James Bach again.

At work we do a lot of testing, and we play a lot of table football. Up-time and down-time; you can’t stare at a screen or a handset for too long before your mind goes blank. Everyone needs a break sometime….

But are the two activities so different? Can testing learn from table football, or can table football learn from testing?

Those of you thinking “of course not”, consider this:

• If you are playing the defender and goalkeeper then you’re trying to stop something (the ball) getting in (to the goal). 
• As a tester you are trying to stop something (bugs) getting out (to the wide world).

• To be great at table football you have to play as a team. It’s difficult to play table football with only one person per side.
• Try stopping all the bugs as a tester on your own.

• The success of a team at table football is decided by who uses the best tactics, the best techniques and the best skills.
• Testing is the same – you can’t catch the bugs simply by hoping you’ll find them.

• Sometimes just hitting the ball as hard as possible gets a goal.
• In testing, sometimes just hitting the product with all your skills, probably via Exploratory Testing or Session Based Testing can find the bugs.

So, maybe our up-time and down-time activities are so different after all 🙂

Today I don’t feel inspired. Something’s just not sparking the creativity. But it has got me thinking; more specifically about inspiration and that spark when software testing.

When someone is testing and they are inspired you can see that. If it’s you then you can feel it; somehow things go quicker, those small problems remain small, and your day goes quick. If you manage testers then you can see it in their eyes, the way they move around (does this sound a little like spying? I hope not), the way they talk.

But how can it be that the thing that inspires us one day doesn’t inspire us everyday? What’s changed? Maybe it’s that 400 page test spec to run through, maybe it’s that software that just won’t even boot, maybe it’s the defect that got returned or ignored again, even though you know it’s important. But as someone once said “the bad things are what make the best things better”; so for all the mundane and boring, there is also the excitement of that new bug, that near darn perfect test cases, and that feeling of pride when a product ships. Take the rough with the smooth some days.

Hmmm – maybe inspiration is coming again……

2 years ago the company I worked for decide to ‘go Agile’. Vast amounts of money were spent, many people were trained, and whole groups were reorganised. As managers, we all took a look at our groups, assessing the impact, assessing the likely damage 🙂 and trying to figure out exactly how it affected us.

I run a test and quality assurance group so the changes affected my teams a fair bit. We needed to figure out the best testers to put in the relevant scrum teams, those who were best suited to a more regression focused role, and those that we could train to move nearer development or into our automated testing stream. So we sat down, we thought, we planned, and it was all going well. Until……

The Test Manager stood up. ‘I’ve been thinking’, he said, ‘Where do I fit in this?’. And he had a point. We’d allocated the people doing the actual technical testing to the scrum teams. We’d trained, we’d supported, and we’d nigh on forced, the product owners to take the responsibility for quality. We’d put in place a framework which enabled them to plan and deliver their fully tested code to the relevant code branch. Had we done our Test Manager out of a job?

Well….stopping and thinking, we looked further. What does a Test Manager do? Planning, coordinating, ensuring test activities take place on time, on budget, are visible, and most importantly they take are effective, resulting in a quality product. Does the need for this change in an Agile environment? Maybe it does, but the cornerstones of a Test Managers’ role do not. I still require someone with their eyes on the testing. I still require someone who can give me the latest execution status, the latest defect count and the latest plans for testing. I still need someone ensuring effective coordination across the teams, both in process and in test execution.

So the role of the Test Manager changes. In small steps, but with similar goals to before. Make sure the results and status of testing is visible, make sure that the processes used are understood and actually used. And ensure ultimately that, at a programme level, the whole group produces a quality product.

So, we hadn’t abandoned our Test Manager to the Agile wilderness, but he’d had to change, like we had, to suit a new way of working.

Come back soon….I’m almost there…..