Do Testers Take Themselves Seriously Enough?

The argument over the importance of software testing, and how software testing should be taken more seriously, is as old as the hills. “Software testing is seen as a second rate career” is the most common thing testers have to fight against, with various degrees of success, normally dependent on the company they are working for and that company’s approach to quality. But do testers really help themselves?

Over the years I’ve been a tester and managed a lot of testers and others involved in QA. More recently I’ve also started to manage a development team, and when talking about careers to developers and testers, the difference are sometimes startling. Most developers had a plan from college onwards, most still have a plan, and it’s been coding. It’s rare you find someone fell into software development by accident. Now compare this with the testers. Some have a plan, some have stuck to a plan but a majority have not. It’s been a case of falling into testing, often from totally different careers or training. Think of it as being in the right place at the right time 🙂

This got me thinking – is it an issue that developers have a plan and testers just found their way into their chosen career? Does this in fact mean that testers have a more broad experience and that actually makes them more rounded individuals? Does this make them better testers? Does it just demonstrate the lack of formal test training in schools and universities? Do we need more certification to be taken seriously? (joke – we really don’t).

Whatever you feel about it, it’s clear to me that only be recruiting sensibly, by inspiring people to become career testers, and by continually sharing and demonstrating that software testing is worthwhile will we swing the balance. Those in the software testing profession should be focusing on those at the start of their careers, not just focusing on test process and continual improvement. I hope to be able to find more testers in it for the long run, and in the middle of a longer term plan for their software testing careers.

My Thoughts on Exploratory Testing (a.k.a. Steve discovers SBTM)

The group I manage make regular use of Exploratory Testing. We even took training, way back in the day (well a few years back anyway), we know about our test charters, we know where to start and where to stop, we understand it’s place in our strategy. It forms a corner stone of this strategy, which we have to enable quality within our projects. Yet to some of us there seemed to be something missing.

As a tester it’s great. We make a thing about exploratory test sessions. There’s coffee and if you are lucky then there is cake too. You turn up, you pick your area and you fill in your charter. Start the clock and go; testing begins. Stop the clock and testing stops, bugs are added to our database and charters are filled in. Coffee is drunk and cakes are eaten and we go home…..

…..leaving a large pile of pieces of paper which are subsequently bundled in a drawer and forgotten. You might argue this is ok, after all “the bugs got raised didn’t they?” This is of course true but as the Test Manager then I miss the ability to learn from the experience, to review the metrics and to understand how to make the next sessions even better.

So recently I discovered Session Based Test Management, James Bach’s take on ET. I know, late to the party again, by about 10 years, but I work for a large multinational telecoms vendor and change doesn’t come easy to us (awful excuse of course). But thankfully we’ve now found SBTM. I love it, you get the metrics you need, the visibility and the control that allow ET to really come to life. We’re focusing on it more now than ever before.

(One tip if you do take SBTM and James Bach’s tools – also use Session Creator; it just makes things so much easier for the testers.

Is Testing Like Table Football?

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……

Test Manager in the Agile Wilderness?

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.

Mobile and e-commerce technical leadership, coaching, training and presenting