Taking a break from the old routine

I’m a regular on many of the testing forums and mailing lists and I’ve noticed recently a very worrying trend. That is that many testers simply cannot appreciate different ways of working. Their way is a Best Practice. But it’s more than that, it’s not just about Best Practices but the vitriol in which they are delivered.

I see posts on forums asking for help on how to solve a problem. The responses are usually stories of success of working X way to which someone replies with Y way. Then someone chips in with Z way and pretty soon the whole thread is hijacked in an argument over which way is better. Mine, mine, mine.

Some of these threads are extremely useful where people learn a new way of approaching a similar problem. Other threads though have a slightly more sinister feel to them.

Now, I’m not one to hold back and I often respond with critical comments to posts but I like to think I never tell people how they should do something…my way. I can offer help, suggestions, stories, advice, mentoring and guidance but I can’t *tell* someone what to do. I have no best practices that will work for other people, just some honest suggestions from experience that could work.

However, when answering forum posts many testers don’t appear to consider the fact that there are thousands of testers out there, all working under different methodologies or interpretations of methodologies, time frames, technology, budgets, skills sets and software development life cycles. Some are working in highly structured environments, some with helpful programming teams, some with middle managers bean counting and some with processes that are old, destructive or wasteful. But it’s their environment and it’s their problems they are asking for help with. So let’s help – not dictate and ridicule.

Over the years I’ve created many many many Best Practices for myself. In fact, every time something goes right, it’s a best practice. Yippee. I have also developed some worst practices too. Boo. And along the way forums, user groups and mailing lists have been enormously helpful in helping me forge my way through my testing life. However, the time has come to stop visiting certain testing groups, forums and sites. To stop subscribing to some LinkedIn and Yahoo Groups; the job feeds are taking over and too many articles have Best Practice in the title.

The sad thing is, the resources are the ones I’ve long been supporters of. Resources that have helped me enormously in the past. Resources that have become the main staple of the testing community. And it’s a shame they are becoming hunting grounds for the Vitriol spitting testers pushing Best Practices.

If the negativity and anger included in some of the replies on these sites is the routine (which it appears it is), then I’d recommend we take a break from the old routine. Unfortunately for many of these forums, this seems to be the action many testers have taken too. No longer are people going to sit through a barrage of Best Practice suggestions, people calling other peoples suggestions ‘stupid’ and people leaving sarcastic comments like ‘maybe you didn’t read the question correctly’. We are not finding it helpful.

There are far too many new testing forums, groups, projects and communities who are there to help. Who still have a community feel. Who still serve the community they are part of. Communities who help testers and grow the community. Whose members don’t try to out-do one another, push their Best Practice as the only solution and degrade and belittle anyone who doesn’t agree – although no forum is ever immune to this, but some forums have a much lower rate of angry testers and vitriol Best Practice pushers.

Now let me clear something up. I’m not talking about people who offer criticism, constructive feedback, honest statements and points of views – sometimes in a heated way – this at times can be healthy – very healthy. I’m talking about people who pick apart other peoples ideas for fun, who say that other ways can’t work, who are so hung up on terminology that it’s painful, who actively take it upon themselves to counter argue forever despite real world success stories, who simply can’t understand that people work in different ways, who have black and white views on automation and who plainly abuse and call people stupid (believe me – it happens quite a lot – and a lot worse sometimes).

And I do sincerely hope that these testers who can’t appreciate contexts come to understand that the testing community is complicated, multi-threaded, diverse and evolving. It’s made up of people with no experience, some experience and a wealth of experience. And in a world where collaboration, community and learning are becoming more valuable it seems alien to be abused for posting on a forum a real and genuine question, problem or response. Sure there are “better” ways of working but there are very few absolute “best” ways of working.

But I’m not going to end of a low note. Nope. For every one of the negative, bullying and belittling testers, there are a thousand welcoming, positive and helpful testers. Testers who are happy to help. Testers who give honest opinions and feedback. Testers who understand that their way may not be the “best” way. Testers who are happy to improve, learn and share knowledge.

And that is a really great thing. In fact, it’s a truly great thing. It makes me glow with pride.

Planning for when cows attack

A picture of a cow
A picture of a cow


A few weeks back at one of the testing conferences I was lucky enough to meet a very interesting man, let’s call him Mr F. He was small, stout and incredibly beardy. He was a fascinating man who had some truly incredible stories to tell. A charming man with a razor sharp wit and incredibly strong opinions. I didn’t agree with 99.9% of what he was saying, but that’s beside the point.

Mr F was telling me a rather long winded but entertaining story around the old saying: “He who fails to plan, plans to fail”

Mr F had worked in the financial industry for most of his career but had recently moved to a big brand web company and was leading the testing of the latest version of this companies new website solution. Mr F explained to me how he planned for everything and anything. He told me, with great pride, how he refused to start the project without a risks and issues register. He even chuckled at the stupidity of the project team for thinking they could start without these crucial documents.

He also explained to me how he set up a team wide calendar entry for everyone to check the risks and issues register daily. He also, with some gusto, explained how he had a wealth of action plans he could refer to when the risks became issues or when the issue was becoming a real showstopping problem. (Note: When I refer to issue I mean an issue that is present and affecting the team/project, not an issue in the software or a defect).

He explained how he spent the first one month iteration finalising the documents ensuring each team member had input to the list of possible things that could go wrong. He had plans in place in case the first release of software was below the quality gate set in his test plan, in case any member of the team was off ill, for power failures, for the loss of test environments, for scope creep, for office security breaches, for testers not achieving 10 test cases per day yada yada yada. He listed very many more. It was a really fascinating (but long) story and I have to say, I was impressed with how much planning had gone in to it. I was also incredibly impressed with how passionate Mr F was for planning for the known, unknown, known unknowns and unknown unknowns.

The problem was that Mr F wasn’t a happy man. It turns out on day three of the second monthly iteration three testers threatened to hand in their notice because of Mr F’s insistence on planning for everything and anything (which, by the way, is an endless and impossible task).

Mr F was then removed as test manager and effectively given the boot. Something I’m not entirely sure he had planned for.

Mr F explained to me how he had never understood that there were different ways of working and that some teams simply didn’t need to plan for everything. He seemed genuinely surprised that different industries used different ways of working and that he faced so much resistance when he asked the team to plan. He said they kept saying things like “let’s just get something done” and “let’s build software, not write pointless documents”.

He’d heard all of the stories of teams just “doing” things with low cost, high efficiency tools and frameworks with only enough documentation and how some teams just seem to get stuff done but he’d  never experienced them first hand. He told me how he had shaken his head in anger at how misguided and misplaced these teams were with their “just do it” attitude without truly realising that there is a world outside of *his* testing domain.

Mr F was still a naysayer of many ‘new fangled’ techniques and approaches like Exploratory Testing, Test Driven Development, automated acceptance tests etc but he was beginning to realise that there are other ways of working and that planning too much in advance was pointless for some teams. It was a hard lesson for him to learn; that there are other contexts out there.

He was a fascinating man but it highlighted to me just how many people simply have no idea there are other ways of working. There were a few others at this same event where I met Mr F who simply couldn’t comprehend that teams are releasing software each month to a high quality without the need for massive plans up front. And this is not agile versus waterfall, some of the stories were of waterfall teams just getting stuff done – and some of these teams were more agile than most.

Planning, it seems, is something many testers love to do. And I believe all testers plan, after all “He who fails to plan, plans to fail”. But there is a point in which that extra planning buys nothing. It is waste. There are always things we will never plan for. Things we will never think of. There are always things we will plan for that will never happen. That is life. It is the way of the world.

Finding the right balance is tricky. Some plans are good. Too many can be bad. None may be very dangerous indeed. What works for one team might not work for another.

I do a fair amount of running and (maybe because I’m a tester) I’ve got a plan for various things happening whilst out running. Like if I fall and break something (the joys of having brittle bones), if I’m attacked by some Hoodies (the joys of living in the UK), or chased by a skulk of foxes (the joys of living in rural Hampshire) or hunted by a massive driver less truck (the joys of watching Duel too many times) but I have never ever planned for being mugged by a rabbit.

But sure enough, one day a rabbit the size of the England Rugby team tripped me up whilst I was running and I swear it tried to steal my MP3 player and new running shoes. I would never have planned for this. I still struggle to believe it even happened. And apparently it’s not that uncommon to be attacked by animals. It was in the news a while back about a man who was surrounded by cows and forced to jump in to the River Thames. And another story about a man being chased home from the pub by an angry badger. But do we plan for these things?

Anyway. I digress. But the point is there are too many variables involved in software development (and life) for us to effectively plan for everything we think we will ever encounter so we need to find that line that exists between careful and necessary planning, and time wasting processes that don’t lead to anything useful.

There are just some things that happen that you simply cannot plan for. So why try? Plan for the basics but don’t spend too long planning for the unknown, for the low probability and for everything you could ever think of. Most of it might not happen and I can guarantee there will be bigger problems you’ve never thought of.

So instead, be ready to accept new ideas and concepts, and be prepared to be flexible in how you approach a problem. But most important of all, be open minded to new ways of working and flexible in how you deal with problems.

And I leave you with a perfect quote:

“One should not respond to circumstance with artificial and “wooden” prearrangement”

And do you know who said that? The legendary Kung Fu master Bruce Lee.