Why I Recruit Based Upon a Belief System

Recruitment is very time consuming and also very difficult in my experience. It’s a bit like buying a house, if the right house isn’t on the market when you’re looking, do you just “settle” for the next best thing or do you drop out of the market and come back later? Unfortunately, when we’re recruiting it’s usually because we need some NOW!

I’ve recruited hundreds of Testers and Test Managers over the past 25 years and have developed several tools to assist me along the way. Behind these tools is my inherent belief that we can teach someone technical and business skills, but we can’t teach them how to be. How to be is usually what matters most when being with other humans. During my later years (since I turned 45) I have applied a rule to my own job searching and that simple rule is that I have to “like” the people I am working with. So, the obvious question is “How do you work out if you like these people”? For me it’s quite simple – I listen to and watch how the people interviewing me respond to various questions and answers that I provide. It usually takes me less than 5 minutes to decide this, so the rest of the interview is about enjoying the chat or working out how to close it down.

When I’m the one doing the recruiting I use my “A to Z of Beliefs” to determine whether I want someone on my team. This list is not cast in stone and I usually share it with my management team so that we can massage it for the specific company or project. The way it works is that we look for specific qualities in the people we are interviewing and if they possess more that 80% of the qualities we believe are important then we offer them a job. Obviously some qualities are more important than others and therefore we usually prioritise the “Top 3” and make sure these three are always present.

You may question some of the beliefs listed below, but as I said these are my beliefs in relation to what is important in creating an effective software testing team. So, here is my current “A to Z of Beliefs” that I recruit to:
Bravery (in making decisions)
Daring (to be different)
Family & Friends
Healthy Lifestyle
Justice (for all)
Knowledge (the quest for learning)
Love (for one another)
New Ideas (open to)
Understanding (of others)
Xcellence (yes, I know that’s a slight cheat)
Youthful (in attitude, not necessarily years)

This approach has worked really well for me in both assessing prospective employees and employers. I’ll be very interested to hear your thoughts on this approach and list.

Dateline: March 12, 2013; Melbourne

How I Became a Samurai Test Manager

During late 2000, I began taking an interest in the Samurai way of life, reading various books and making a short trip to Japan. This interest culminated in me presenting a paper at EuroSTAR 2002 in Edinburgh, Scotland entitled “Testing 2 Die 4”. Since then I’ve employed these learnings to great effect in my role as a Test Manager and Change Consultant. Here is a précis of my journey….

To start with the basics – the word Samurai means “to serve (with pride and passion)”. It is a common misconception that Samurai were warriors and/or fighting machines. The truth is that they were loyal servants of their lords and masters who only resorted to violent confrontation if all else failed. Among their beliefs was that you do what is appropriate, maintain perspective and focus on ideas (not opinions). For me, this translates into today’s context-driven testing techniques and holistic management styles.

Samurai focused more on “being” than doing. Being “in the moment” is far more efficient than looking to the past or future. Making a decision based upon feel/instinct (of the current situation) is far more effective than pouring over history or defining numerous (possible) outcomes. Feel is usually the result of countless hours of practice and preparation, so that when the time comes to act you act swiftly with precision and certainty.

Timing is of the essence (when it comes to action) and therefore knowing when to act and when to wait is paramount. When to apply pressure and when to back off also falls into this category. General Patton once said “A good idea executed today is worth a dozen perfect ideas executed next week”. In many of our Testing scenarios we wait for optimum circumstances, yet we can achieve our goals far more effectively and efficiently if we are prepared to compromise on some of our expectations. Perfection takes too long, we cannot control all of the variables.

Paying great attention to detail is another primary skill. Effective Test Management requires the ability to see the big picture, but also get down into minute detail; often needing to move between these states almost instantaneously. Defect Triage is a good example of where this becomes very useful as we may be discussing the precise activity of a piece of code while relating this to an overarching organisational function or process.

The study of other professions and practices is also key. I have consciously moved between as many industry and government sectors as possible in order to provide the most flexible and rounded perspective for my clients and customers. Moving from a Test Management role with a Tier 1 bank to an Organisational Change job with a small Transport business and then onto running a major Test Practice gave me plenty of opportunity to study the different types of people and practices found in these businesses.

Staying current with new techniques (and technologies) is also essential. Being able to discern fads from future staples is very key here. If you jump too early (with a new technique) you may end up down a blind alley and if you jump too late, an opportunity has been missed.

You must invest in your team as well as yourself in order to ensure that staleness does not set in. Ordered flexibility is a concept based upon the various states of water. If we are too rigid in our thinking, stubborn and closed to new ideas we will perish. Water adapts by freezing or steaming, returning to a fluid state when the circumstances permit. Water moves around an object, rarely through it; thereby, wasting no time on unnecessary actions. Water evaporates and takes the higher ground in order to return as rain and therefore sustain a larger terrain. We must learn to be flexible in our approach and skilful in our execution. We must know when to re-group and find another path to a better outcome.

Fear of failure is another area of focus. We must visualise success and the steps to get there. There is no advantage to an outcome if you dwell on (possible) failure. Acting in fear just constrains your actions and reduces your chances of success. A Tiger is always a Tiger, no more, no less. You stand a far better chance with your eyes wide open and your spirit calm. However, this must not be construed as an attitude of “certainty” (in an outcome), as this will also undo you and lead you to overlook minor details and almost certainly lead to the failure you were fearing.

Finally, in our brief introduction to Samurai Test Management, we must consider focus. Focus is essential if all the other elements are to be effective. Our focus should always be on weaknesses and where we find the most weakness we must attack with the most ferocity. If I am interviewing someone and I feel the potential team mate has a weakness (and we all do) I take several routes around the weakness and decide whether or not to disclose it. I need to know far more about the weaknesses of potential team members than their strengths as it is their weakness that will undermine our success, while their strengths are usually a bonus. I recruit based upon attitude (fundamentally pride and passion) and flexibility. A passionate committed Tester who is flexible is worth ten technically-sound but inflexible/opinionated practitioners.

As I said at the beginning, I read extensively and studied hard to understand and apply these techniques to our profession and two of the books I still have in my Test Managers Toolkit are “The Book of Five Rings” by Miyamoto Musashi and the “Book of Five Rings for Executives” by Donald G Klaus. I recommend them both unreservedly.

If you want to see my original (Testing 2 Die 4) presentation from EuroSTAR 2002, you can retrieve it from the EuroSTAR archive, along with the other presentations I’ve given at that Conference. It’s only a black and white PDF, so if you would like a copy of the original in full blown technicolor with Samurai background graphics, just reply to this blog post for a copy.

As a final offering, I wrote several Haiku (traditional Japanese verse) when I originally presented this paper and here is one of them – remember this was written over 10 years ago and the technology has (thankfully) moved on.

Windows NT crashes
I see the Blue Screen of death
No one hears my screams

Dateline: Bagshot, Surrey; Friday February 1

Do Testers Really Need Coding Skills?

This week’s Blog comes with a Rant Warning. So if you have no interest in someone (passionate about his profession) going off, then look away now; otherwise, don’t say I didn’t warn you….

Why are so many people in our profession writing and talking about the importance of Testers having coding/programming skills?

It’s as if you’re only a real Tester if you can write code. Give me a break. This is a myth perpetrated by the (self-styled) clever people, who would like to create an elite class of Testers. It’s tough enough teaching and coaching young people in the art and science of software testing, without confusing them with this sort of rubbish. If you don’t understand fundamentals like Boundary Value Analysis, Equivalence Partitioning, Risk-Based or Triage techniques, Root Cause Analysis and are able to communicate clearly and succinctly, then you aren’t worth jack-s**t to me, as a Tester.

I put the (Testers must also be Coders) myth into the same bucket as folk only wanting to test in an Agile environment or with (Mobile) Apps. Why does everyone get hooked up on doing something that the marketing drones tag as cool? Being cool has nothing to do with the job you do or the techniques you use. Being cool is a state of mind and most of us don’t have it. Clooney and Pitt are cool. Muhammad Ali in his heyday was cool. Lance Armstrong was cool once upon a time!! Louis and Neil Armstrong were cool…

If someone thinks that some of the stuff I do is cool (unlikely I know) that’s fine, but don’t then label my physical form with the same badge. At best, I’m an average hard-working guy who has toiled for years to be considered for the toughest assignments around and then tackles them head-on with relish on the side. I take my job seriously, but not myself. I endeavour to be better than 99% of the population, at what I do, but I don’t do that to be cool or to satisfy my ego. I do it to give my family a better lifestyle and greater opportunities. I also do it for my Test teams, to give them the same skills and initiative to achieve what I’ve achieved.

As most of you will know by now, I am entering the last phase of my career and therefore I am working on giving back as much as possible to those following in the same profession. It’s a great profession and has provided me with some fantastic opportunities with some amazingly intelligent people, who I have been fortunate enough to learn from. I have been blessed, but I’m definitely NOT cool.

Why are you cool if you test on Agile projects? Why are you cool if you have experience testing Mobile Apps? This year’s Mobile Apps were yesterdays WEB sites. Those of us who wrote the “WEB Testing Book” didn’t think we were cool. Breaking software is breaking software and I can break any software I care to interact with, not because I’m special, but because I have a series of processes and techniques that find and exploit weaknesses. It’s my innate mindset and years of hard slog that have allowed me to do this – NOT being cool. Sure, I can write code, but does it make me a better (black box) Tester? NO, NO and NO. It gives me a slightly different perspective on the software world, but it hasn’t made me a better Tester.

Over the last 10 years or so, I have been working with more and more folk who think that building a resume is more important than learning the craft. Not too long ago I spent two years working with IBM; mainly because they were an organisation that I had always admired and therefore wanted to work for. However, I didn’t chase that opportunity – they came to me (on the back of some work I’d been doing alongside them on one of the largest and most complex technology-driven Programs of Work ever undertaken in Australia). I had a ball (at IBM) and worked on one of the best projects of my career during that time (I’m not going to name it now, as in a later Blog I’m going to describe my “Top 3 Projects” and why they are at the top of the list).

IBM do some really cool stuff, but they also make mistakes and their takeover of Rational Software was (and still is, in my humble opinion) a missed opportunity. During the period when the (Rational) takeover was taking place, Mercury Interactive (now HP) stole the pre-eminent position in commercial software testing tools – a position they have been protecting ever since. A position that I have never believed they deserve. They have great (although misguided) sales staff, but generally sub-standard products. Why else would the open source and freeware tools be killing them over the past couple of years?

To end on a slightly different subject, I want to talk about my Dad and the impact he has made to my life. My Dad is very working class and very “old school”, although he wouldn’t recognise that term. He has influenced my life immeasurably and has given me so much in terms of values and ethics. He taught me the importance of family and loyalty. He taught me that hard work and endeavour will win out over natural ability and intellect – invaluable lessons in the professional and sporting worlds that I have frequented. He taught me to love and cherish those around me. He taught me not to be afraid to try new ideas and that failure is ok – as long as you learn something from it. He showed me love every day of his life – a life that may be coming to an end very soon.

I’m currently in the final hours of a flight from Melbourne to London (my second in the past three months) to support my Dad in what appears to be his final battle with a terminal heart condition. I’m hoping to get there before he leaves for a higher calling. I’m hoping that the pain he has been experiencing for the past few months is being dulled by the drugs they have recently started to give him. I’m hoping that I get at least one more chance to say goodbye to him face to face, rather than through the surrogate that I have been using these past few days. I’m hoping that the rest of my family are not suffering as much as he is.

I hope that my Dad would be proud of my Blog (even if he didn’t understand the technical aspects of it). You see, my Dad, was big on doing “the right thing”. He was big on being true to yourself – ahead of pleasing others. He would have encouraged me to “rant” – if he thought it was for the “greater good”. He would also have discouraged me, if it was not in the best interests of my career. Fortunately, I don’t care too much about my career prospects these days and can write pretty much whatever I care to. So, to those of you still with me at the end of this latest Post, thank you for sticking with it. It’s been quite a journey this week, in more ways than one and I hope you’ve gained something from it – I know I have. I’m going to be in Europe for at least the next few weeks supporting my family through this latest sadness but I’ll also continue blogging as I need the occasional distraction to ease my own pain.

Dateline: “Somewhere over mainland Europe”, Friday January 18, 2013

Why Test Managers go on Stress Leave

Being passionate about my job has got me into more hot water than a cooked lobster. I have the burns to prove it. When I first started out on my quest to understand software testing (and ultimately Quality Management) I took the approach that I had always taken with the passions in my life – I embraced everything and everyone and fully immersed myself until I understood the very essence. The result, initially, was pretty messy. But I did come out the other side with greater perspective and harmony – although some of you who have worked closely with me may think I’m being over-optimistic here.

Software Testing is often a challenging/thankless task with many bloody battles fought and lost in the search for quality nirvana and the higher up the corporate ladder you go the bloodier the battles get.

The fact that I’m even writing in this tone is an issue. Why do I think in terms of a quality battle? Because – that’s the dance I’ve been part of for most of the past 30 years. There are many stakeholders in the running of a business and many of them have an opinion (however misguided) on how much money should be spent on testing the software that supports and/or drives their business.

I’ve taken up the Quality/Risk mantle on far too many occasions for my own good. “We must do more Testing” was a line I used far too often before the grey hairs began to appear exponentially. That was until the day Phil King (an exceptional human being and ManU supporter) and I shared a taxi in Sydney and he challenged me on my thinking around software testing and it’s place in the business change universe. It was 1996 and Phil was the CEO of Planpower (my employers at that time) and he wanted to understand how much our company should invest in what I was peddling at that time. So we talked about all the stuff CEO’s care about when running their businesses. We worked on our blueprint and when I left Planpower four years later it had grown (from a fledgling 5 personnel in 1995) to over 300 amazing consultants and was being primed for sale by the four owners. Today, Planpower is still an integral part of the UXC Consulting empire.

As I have said before, software does not exist within a vacuum, it is fully connected to everything that exists and therefore it must obey the same forces of nature as the rest of us. Time is finite. Money talks. Great people are in short supply. The are far too many meetings that discuss bug numbers instead of risks and consequences.

Passion is a very powerful emotion that can transcend culture and beliefs. Normally placid colleagues can suddenly become whirling dervishes if you criticise their ideas or question their design. “Who made you the gatekeeper of quality and where did you get the idea that Quality Management is an activity?”

All too often the Test Manager takes on the role of Quality Champion without ever understanding the organisations strategic views on what is considered good enough or high/medium/low risk (in terms of running the business). How can we (yes, I am a Test Manager) then take ownership of the quality of the software when we are often not engaged until the solution is already half cooked? How can we assume responsibility for the quality of an outcome when we had no involvement in the original business meetings held to discuss a problem and whether it needed fixing?

When I wrote (late last year) that the majority of Testers have no desire to become Test Managers it is this sort of behaviour that the Testers see and want no part of – it’s a no-win situation…. If you are a Test Manager then your job is to manage (and possibly strategise) the Testing – not take on all-comers when it is time to triage the latest bug hunting safari. You are there to represent the efforts of the Test Team, not to pass judgement on the impact of a specific bug remaining unfettered when the “Go Live” date arrives. This is the domain of the business representatives.

I have witnessed countless Test Managers go on stress leave due to the contortions they put themselves through in the name of the Quality God. They lost sight of the independent role that Testing should play and became embroiled in the cross-fire between the Business Owner(s) and Project Manager. Provide the ammunition, but don’t ever fire the gun!!

Stress is something we take on, not something that is given to us. Stress less and have fun, that’s why you’re doing it – because you enjoy it.

Epilogue: As an addendum to this week’s Blog, I want to dedicate this article to a very dear friend of mine who passed away this week after losing a four month fight against cancer. Pat, you will be missed by all who came into your universe and I look forward to seeing you one day when my journey on this planet is over.

Dateline: January 9 2013, Doncaster, Australia

Test Managers Toolkit: The Model Office (Part 1)

I am constantly amazed at how many Test Managers have never used my favourite (and to date, most effective) Testing technique – the Model Office. In fact, I’m even more amazed at how many Test Managers have never even heard of a Model Office. Where have you all been the last 20 years?? A search on Google supports my assertion – that it is an under-utilised technique. Only one of (what I consider to be) our Testing thought-leaders (Paul Gerrard) mentions it on his website, all other Google references are from non-Testing practitioners, generally Program/Project Managers or Architects.

So, what is a Model Office? Simply put, it’s is a (scaled) replica of an entire business (or sometimes a clearly defined sub-set of functions or departments within a business). It is a model (generally) defined in both business and technology terms to depict how an organisation works. Typically, at the centre of this model is a level 3 process/workflow map (or maps) depicting how stuff happens, who does it (and when) and what outcomes occur as a result of stuff being done. It’s major benefit is that everyone gets to see what the organisation looks like today and how it will look in the future, once the changes you are making have been implemented. Some folks describe a Model Office as a simulator, but I prefer to think of it as scaled-model where real-world scenarios can be tried and tested – even before you start to build the solution.

My most successful applications of a Model Office have been on significant organisational change type projects where we have built a physical manifestation of the current state and overlaid it with the proposed solution. We do this by expressing the current organisation as level 3 process maps using sticky notes and then covering these with a see-through material and then placing more sticky notes on this cover where the changes occur. This provides a before and after series of images that can easily be modified by simply replacing the offending sticky notes. Once we have these pictures approved (by the various stakeholders) we commit them to whatever software we are using to build the long-term process maps.

Examples of Model Offices we’ve created include:

  • A Branch of a Retail Bank – so realistic that customers tried to come in and perform their daily transactions (we set it up in the foyer of the bank’s Head Office for maximum visibility)
  • A complete online Supermarket that encompassed everything from product-line buyers, a mini warehouse, real delivery trucks and “friendly” customers who ordered and received free produce for 3 months
  • A Supply Chain business that was being transformed via a complete technology overhaul
  • A Business Bank that was undergoing a major merger
  • A government department implementing a new Training and Development package

Four of these program’s of work were delivered successfully, while the fifth was canned based upon information gathered using the Model Office during the solution design phase.

I have been using this technique for over 10 years and the biggest challenge is generally gaining buy-in from the technology stakeholders – business stakeholders are always supportive of a business-centric Test Strategy.

So, why haven’t you set up (or considered setting up) a Model Office in your organisation? The most common reasons I come across are:

  • Lack of strategic knowledge or technical understanding of the Model Office technique (you won’t find it mentioned in the ISTQB syllabus or glossary)
  • Lack of insight/foresight as to the short and long term benefits
  • Lack of ability to convince potential sponsors to fund it
  • Lack of a suitable location or space – some Model Offices require significant physical space

When we were Testing the Supply Chain business we were allocated a (spare) warehouse with an office that overlooked the main storage area, so that we could monitor and record all the warehouse-based functions in real-time.

Unfortunately, not every organisation is willing to provide this level of support; however, this is not a show-stopper and your powers of creativity just need to be exercised a little more. As I said a couple of weeks ago, I’m currently on the road in Europe and therefore don’t have access to my entire Test Managers toolkit and therefore I can’t attach a multitude of photos of some of the Model Offices I’ve designed and implemented, but I will rectify this once I am back in Australia.