D is for Dauntless (My A to Z of Software Testing, Part 11)

About three years ago I wrote a short series of Blog posts that changed everything in my blogging world. It was a series that culminated with My final word on software tester certification. This blog post was read over 1,000 times within the first 24 hours of publication and to this day is by far the most read and most commented on piece I have published on this Blog. The reason I bring this up is not to self-promote but to present the context within which it was written and to also provide an up to date perspective – after all, three years is a long time between drinks!!

One of my main reasons for starting this blog was to provide real world experience from a very personal perspective – wearing my heart on my sleeve, if you like. I believe I have always done this and the certification posts have certainly come from the heart. The reason I took this approach was to (hopefully) provide an insight into real-world every-day issues that people within the software testing sector face. It was never my aim to say “this is my way and it is a good way” or “if you take my advice you will….. blah, blah, blah”.

Wearing your heart on your sleeve requires a certain amount of bravery, fearlessness, resoluteness and daring; in a nutshell, being dauntless. Some of you may not see Testers as brave, fearless, daring or resolute but for me they have come in very useful on many a day spent in the quagmire that surrounds much of our technology-driven job. It takes bravery to say “I want to stop testing (our multi-billion dollar project) because our test environments are too unstable“. It requires fearlessness to stand up in front of a board of directors and tell them (the business that they have just spent millions bringing to fruition) “I think we should give away free produce for the next three months in order to prove our processes and business model“. It requires resoluteness to tell a CIO “the software won’t be good enough to launch next week, in fact it probably won’t be good enough next year!“. And it requires daring to ask the sponsors of a major logistics company rebuild that “I want to spend some of your budget buying toy trucks and model trains“.

I have done all of these things I describe above during my software testing career and all of them were accepted and each contributed significantly to successful software implementations.

My main reason for sharing these stories today and writing about being dauntless was driven by several recent blog posts that I have read where people seem to be frozen by fear or constrained by controversy. If you believe (and can prove beyond reasonable doubt) that a specific action (no matter how wacky or left-field it may be) is the best option available – go for it and be DAUNTLESS. It will give you the strength and confidence to strive to make a difference. It will show the rest of the software development structure that software testers bring a perspective that can add millions of dollars to the bottom line of a business. It will give you the strength to remain resolute and become a better Tester….

Dateline: Bagshot, Monday July 18, 2016

E is for Expectation (My A to Z of Software Testing, Part 10)

My daughter Hannah is expecting a baby girl that will arrive into a post-Brexit middle-class English countryside sometime in the next four weeks. Project Baby Denhart has been almost 9 months in development and so far the only testing that has taken place has been of the stress-related kind, with Hannah handling the increasing pressure of a front-loaded mound that is beginning to bear an uncanny resemblance to the one built by Richard Dreyfus in Close Encounters.

As with many an idiom that dots the English language landscape, expecting a baby is a case of stating the bleeding obvious. After all, once a human pregnancy has been confirmed the prospect of expecting anything other than a small humanoid outcome is, well, frankly, absurd. If only software projects were as straightforward!! In my experience software project expectations can lie anywhere between the solution to world hunger and the removal of that annoying little blue screen than pops up every time you press ENTER!!

Expectation management is one of the most crucial factors on any successful project – and so many folks get it spectacularly wrong. As a Test Manager of over 20 years I can state categorically that setting (and truly understanding others) expectations is one of the top 5 fundamentals of successful management and leadership. So, here are my top tips for effective expectation setting and understanding the expectations of others.

Col’s Expectation Tip No. 1 When I am interviewed for a role I spend as much time describing my weaknesses as I do my strengths – no one is brilliant at everything and I’m no exception

Col’s Expectation Tip No. 2 If I promise to do something, I do it to the best of my ability

Col’s Expectation Tip No. 3 If I can’t do something (due to my lack of skill/capability or lack of time) I say so very clearly and emphatically

Col’s Expectation Tip No. 4 I don’t need to exceed expectations, I just have to meet them (if I get into the habit of exceeding expectations the bar just keeps getting raised higher and stuff becomes unsustainable)

Col’s Expectation Tip No. 5 I say “No” sometimes – I gain more respect for saying “No” than for saying “Yes” and failing to deliver

Col’s Expectation Tip No. 6 I only set expectations for others that I can achieve myself – and then I give them all the support I can to help them meet them

Col’s Expectation Tip No. 7 I expect my teams worst to be better than everyone else’s best

Col’s Expectation Tip No. 8 I will support you 110% if you respect my reasons for disagreeing with your idea

Col’s Expectation Tip No. 9 I expect to win, but I will applaud and support you if I lose

Col’s Expectation Tip No. 10 I will never be perfect, but I will endeavour to improve every single day

Dateline: Melbourne, Thursday July 7, 2016

M is for Memory (My A to Z of Software Testing, Part 9)

My brother Paul and I shared the majority of the first twenty years of our lives in a small semi-detached house in the south-east of England. We were born just 17 months apart and so we experienced many of the wonders of growing up together. When we were toddlers my Mum would put us in the same bed if one of us caught measles, chicken pox etc., in order that the other get it at the same time. We went to the same schools. We joined the Cubs and Scouts together. We both got newspaper delivery rounds at the same shop. We shared a butcher shop job (so that I could duck out to play soccer for the school on a Saturday morning). We occasionally dated the same girls. We both left home and got married in the same year. He even emigrated to Australia, a few years after I moved here, although he and his family couldn’t settle and so they moved back to London after 6 months.

As you can see, my brother and I are pretty close. However, if you ask us to relive some of the more memorable moments in our lives I can guarantee you that we will provide quite different recollections to many situations. I’ve always been fascinated by the fact that two (or more) people can attend the same event (let’s say a soccer match) but can come away with completely different memories – and that’s even taking into consideration the bias based upon supporting opposing teams. My wife and I watch our Aussie Rules team regularly, but when it comes to recounting the highlights we can both have distinctly different memories.

So, how does this happen and what is the link to software testing?

Firstly, it happens because we have different perspectives and contexts. We look at the same action, but we don’t always see the same activity. I see the player passing the ball, while my wife sees the player missing the tackle. I follow player X across the field, while my wife follows player Y.

It is therefore not surprising that when we are asked to test a piece of software each of us sees it from a different perspective. Even if we’re are working from an identical script and are directed along an identical path we can recollect different feelings and experiences. And this is where memory is fascinating, for me. We look, but we don’t always see. We listen, but we don’t always hear. We eat, but we don’t always taste. UNLESS….

I practice living in the moment. It’s something I read about roughly 20 years ago in a tale about a samurai. As a result of this book (and other similar works) I practice BEING first and doing second. I practice cognisance. When I am playing tennis I feel the ball striking my racket and visualise it hitting the line at the other end of the court. When I am cycling I constantly monitor my muscles and my breathing, in order that I may respond to the terrain or traffic, so that I am not just reacting.

When I prepare to test software I visualise what I want to achieve and this helps me reconstruct my memories afterwards. We recently went on a fantastic trip to the USA and my memories are still very clear. I believe this is because I planned the trip carefully, visualising what we would do and where we would go. It meant that I could be truly present and living in the moment. I can still taste the amazing meatloaf I ate at The Perfect Wife restaurant in Manchester, Vermont almost 3 weeks ago!

Eight years ago this week I travelled to Stockholm on my first visit of a new assignment to resolve some serious testing issues with the city’s (soon to be implemented) smart ticketing system. I still remember very clearly my first encounter with my “standing” desk, my early morning lift encounters where I would greet someone in Swedish, but then be unable to continue the conversation past the weather! I remember the taste of lingonberry sauce with my reindeer meatballs. I remember uncovering the root cause of their software fragility and source code management issues. I spent six months commuting between Melbourne and Perth in Australia and Stockholm, Sweden and still remember each individual trip to the northern hemisphere as if it were last month. 2008 was the year I learned how to be truly present and to live in the moment. It was also the year that my memory began to improve and I began to see far more clearly how BEING was more effective than doing.

Dateline: Melbourne, Friday June 24 2016

V Is for Value (My A to Z of Software Testing, Part 8)

What is your value as a software testing professional? Is it just the salary you command or is it something more? Can you manipulate your value? And, if so, how?

I’ve written about how I assess and hire software testers in the past, but the focus then was on attitude. This time I’m taking a slightly different tack and looking at value by focusing on the time before you are in the room with me. This is about how you get to the point where you believe you have sufficient value to even be talking to me about working with and/or for me.

I have incredibly high standards regarding my own abilities and therefore I also have high expectations regarding those I employ. Your value to me (and my organisation) is contextual, based upon a number of factors. The main ones being flexibility (where and how I can use you), technical capability (how appropriate are your skills to my challenges), self-sufficiency (how much guidance do you require to be able to get the job done) and durability (when the going gets tough etc.). As I have said in the past, these are secondary to my number one requirement, which is your attitude.

So, how do I assess your value with regard to each of these capabilities?

With respect to flexibility, the main criteria is based upon your capability to perform multiple roles within the team. You have very little value if you can only perform one role for me. On the other hand if I can use you in a wide variety of roles (they don’t all have to be to the same level of competency) I will see you as a very valuable team member. In sport we talk about utility players or all-rounders. There are players who can play in multiple positions for the team and therefore (among other things) can provide extra cover when injuries or suspensions occur. Flexibility is also a state of mind and this is essential in the ever changing world of technology.

Secondly, we have technical capability. There are far too many technical capabilities that can be listed here, but proficiency comes in many shapes and sizes when we talk about testing software. For me, problem solving and pattern recognition sit at the heart of our profession and what makes these so key is that they are hard to learn. However, the more technologically focused proficiencies are all learnable and therefore your ability to take on new ideas and techniques is also key.

Thirdly, we have self-sufficiency. Even if I am hiring you for a junior role I expect you to be able to think on your feet and be creative in your solving of problems. These problems can include the investigation of something you have no prior knowledge of or seeking out those who do have the knowledge you require. My style of management and leadership is one of providing a goal and some context and then allowing you to find the simplest and most efficient way to achieve it. This may take several iterations of thinking and analysis (with occasional input form me) but you do the groundwork and I will typically point you in the direction that seems most appropriate based upon my own understanding and analysis. It is absolutely key for me to allow those working for me to develop their own way of doing things as I don’t want a team where everyone thinks and works in the same way.

Lastly, we have durability. What I mean by durability is your ability to rebound from setbacks, recover from errors in judgement and hang in there when we have tough days and tough assignments. I build supportive and caring teams and therefore your ability to empathise with and support others (when they are struggling) comes under this heading too.

Dateline: Melbourne, Monday June 13 2016

P is for Patrick (My A to Z of Software Testing, Part 7)

“P” was going to be for Passion, but then I thought “that’s too passé, why not encapsulate the essence of passion instead”. Patrick is a genuine, down-to-earth kinda guy who has provided me with an enormous amount of inspiration and support over the past couple of years. In fact, I’ve never told him this, but when I was planning to close down my Blog, early last year, it was Patrick who inspired me to carry on. Sometimes we need someone on the outside to slap us back into line!!

Patrick is one of those people you bump into one day and they immediately make you feel that your day is better for having met them. It may come as a surprise, to some of you, but we didn’t even meet face to face for me to form an opinion that this man was going to make a difference to my life. And so it was, roughly 9 months after we first exchanged “online hellos”, that Patrick did something for me that will live with me for the rest of my life.

I was aware that Patrick had a hobby (and a small online business) carving and selling wooden objects. I knew this because he would provide vivid descriptions of his “shed time” via his Twitter feed. I also knew that he was scaling back his wood carving activities. However, this did not deter him from creating a magical wedding present for my daughter and her husband-to-be.

I finally met Patrick, in early November last year, while we were both attending the EuroSTAR software testing conference in Maastricht, Holland. It was like meeting up with an old school friend, someone you know that, even if you only catch up every 5 or 10 years, you will instantly reconnect and have a great time. We spent far less time together that I had hoped, but we were both there to work and my trip was a very last minute affair, so my planning was haphazard to say the least.

What struck me most about meeting Patrick in person was that he had an air of calm and grace. His smile was infectious and warm and I felt happy in his presence. Patrick has never told me that he is passionate about his work (or about anything else for that matter), it’s just blindingly obvious from the way he conducts himself. In fact, he is self-deprecating and slightly vulnerable around the edges. There is a subtle humanity to this man that will serve him greatly as his stature in our community grows.

If all this sounds like a classic “bromance”, I make no apology. My blog has always focused on my personal view of the software testing business and community within which I reside and Patrick is an integral part of that community. If you too want to meet Patrick you can find him (as I did) on Twitter @TestPappy or via his Blog at http://www.TestPappy.wordpress.com

Dateline: Melbourne, Tuesday May 10, 2016

Postscript:- Kirsty McColl was a vastly under-rated singer/songwriter who wrote a classic pop song entitled “Patrick” – somewhat profoundly it appeared on my iTunes playlist just as I was finishing this post!!

R is for Reputation (My A to Z of Software Testing, Part 6)

The other day I got this call – “How ya goin’ Col? Keepin’ alright? Listen mate, we’ve got this really difficult client. You know the sort, crap culture, poor user management. We can’t trust anyone else. If you’re not too busy could you help us out by going in and sorting it out?“.

This wasn’t the first time I’d taken this sort of call – and it probably won’t be the last! No prizes for guessing why I get these calls. You don’t have to be an Einstein to see that I have a reputation for this sort of thing. Do I mind? Of course not. We all like to feel wanted, even if it is to shovel the shit that no-else wants to!! The truth is, I love a challenge and the worse the situation the bigger the upside when I succeed. Don’t get me wrong, I won’t do anything. I’ve walked away from crazy projects, but that’s been because the Project Manager hasn’t respected me and/or my team.

Reputation touches our lives on so many levels. There is the reputation of the country we live in – I live in Australia, which has a reputation for sunshine and beautiful beaches. When I tell people that we have wonderful ski resorts just a few hours from those beautiful beaches they look at me very warily.

Then there is the reputation of companies – the ones we would walk over coals to work for or those we wouldn’t touch with a barge pole. I have my own lists, I’m sure you all do.

Even our profession (software testing) has a reputation. In my personal experience, software testing has had the reputation for being unnecessary (our software developers are brilliant), expensive (compared to what?), difficult (to understand the value of), easy (anyone can do it), and the list goes on and on. How can something as nebulous as an activity gain a reputation? Well, the truth is, it usually has something to do with the personalities of the protagonists.

As Shakespeare once wrote – “Reputation is an idle and most false imposition; oft got without merit and lost without deserving” (Othello, Act 2, Scene 3).

A few weeks ago I ventured out into social media land and asked folks to provide a single word that encapsulated how they think of me. I wanted to get a (simplistic) handle on my current reputation. I wanted a single word because I felt that asking for more would take away the spontaneity of the reply. I didn’t want platitudes or kudos, I just wanted the truth. Also, I didn’t care how well those people knew me, because reputation doesn’t have boundaries. The greatest number of responses came from LinkedIn, which is interesting in itself as that’s my professional reputation we’re talking about.

I was going to list the feedback here, but then I thought “maybe that will influence how others think of me”. If you really want to know what others think you can find the list on my LinkedIn profile, under the request I posted on April 21, 2016. 

So, what did I make of these responses and do they matter? First of all, they matter to me because someone has taken the time to think about how they view me. Secondly, these responses make me feel humble and vindicated. Humble because I find it hard to see myself in these terms. Vindicated because I’ve spent most of my life bucking the system and refusing to bow to a herd mentality. I do not hide behind agendas or play politics, I just keep it simple and act within my abilities – never afraid to say “I don’t know” or “What do you think of this?”. If you are a regular reader of my Blog you will already have a sense of these traits through my writing. I’m no scientist, psychologist, engineer or poet, but I understand enough about each of these roles to successfully navigate my way through most of what my professional life has thrown at me. Of course, it hasn’t all been plain sailing, but then if it had been, I wouldn’t have learned so much and I wouldn’t be the person I am today (warts and all).

Just over twenty years ago I learnt a very salient lesson that has stood me in good stead ever since. I was leading a small team of developers and testers at a second tier bank in Melbourne. We had (the usual) tight deadlines and crazy management expectations about what we needed to achieve. Fortunately, we were a tight-knit bunch and we had a great vibe going. We worked hard and played hard and met every challenge thrown at us.

One particular Monday morning (after working most of the weekend on a late software release) I was called into my Manager’s office. I was expecting some recognition for meeting another milestone. What happened instead bewildered me. My Manager told me that we were gaining a reputation having “too much fun” and that this must be (adversely) affecting our work.

How do you call your team together and tell them that they are having too much fun and that they aren’t working effectively enough? How do you ask them to back off and tone down the behaviour because the other teams around them aren’t happy? My answer? I didn’t do anything of the sort. In fact, what I told them was that we would step up our game even more, have more fun and work even harder (when we had to) – and we did!!

I used to be almost flippant about any reputation I may or may not have, but these days I am far more measured and circumspect and therefore my message (based upon what I have learned over the past 40 professional years) is this…

Go placidly amid the noise and haste, and remember what peace there may be in silence. As far as possible, without surrender, be on good terms with all persons. Speak your truth quietly and clearly; and listen to others, even to the dull and the ignorant, for they too have their story. Avoid loud and aggressive persons, they are vexations to the spirit. If you compare yourself with others, you may become vain and bitter; for always there will be greater and lesser persons than yourself. Enjoy your achievements as well as your plans. Keep interested in your own career, however humble; it is a real possession in the changing fortunes of time. Exercise caution in your business affairs, for the world is full of trickery. But let this not blind you to what virtue there is; many persons strive for high ideals, and everywhere life is full of heroism. Be yourself. Especially, do not feign affection. Neither be cynical about love, for in the face of all aridity and disenchantment it is perennial as the grass. Take kindly to the counsel of the years, gracefully surrendering the things of youth. Nurture strength of spirit to shield you in sudden misfortune. But do not distress yourself with dark imaginings. Many fears are born of fatigue and loneliness. Beyond a wholesome discipline, be gentle with yourself. You are a child of the universe, no less than the trees and the stars; you have a right to be here. And whether or not it is clear to you, no doubt the universe is unfolding as it should. Therefore be at peace with God, whatever you conceive him to be, and whatever your labours and aspirations, in the noisy confusion of life, keep peace in your soul. With all its sham, drudgery and broken dreams, it is still a beautiful world. Be cheerful. Strive to be happy.

Dateline: Melbourne, Tuesday May 3 2016

* Final paragraph is from Desiderata by Max Ehrmann

O is for Optimism (My A to Z of Software Testing, Part 5)

A few years ago I thought we’d seen the last of the (outlandish and absurd) claims around the capabilities of software testing tools, but it appears that we are now going through a new phase driven predominantly by the “every tester needs to learn how to code” mantra.

I am revisiting the capability (or not) of software testing tools after reading two intelligent blog posts by @TestPappy (Patrick Prill) and @therockertester (Lee Hawkins) over the weekend. Patrick wrote a post entitled “Test Automation – Am I the only One?” while Lee wrote “More on the commoditisation of testing“. Both of these posts tackle the various expectations and capabilities of software testing tools, but from completely different perspectives. Patrick has been on a 3 year journey to implement a test automation framework, while Lee highlights claims made by the Head of QA at UBS and the impact test automation will have on headcount and budgets.

My story is one of expectation and risk management. To provide some additional context, I will provide some details of my background and experience to show that I have the credentials to write on this topic. I began writing software over 40 years ago and still dabble to this day. I began testing software the day after I wrote my first lines of code. I designed my first test automation framework in 1999. I have managed over 25 programs/projects where software testing tools were an integral part of the process. I have given keynotes on the challenges of implementing software testing tools.

So, here’s my tuppence worth…

Ever since the dawn of time men (and I mean men NOT women) have been over-optimistic about their capabilities. Ever since the first days of the industrial revolution men have believed that no matter what problems they create (let’s take global warming as a current example) they will be able to fix them with more technology. Ever since the first computer software project was initiated men have under-estimated the time and cost and over-estimated what will be delivered. I have NEVER worked on a single project that delivered everything it set out to, let alone on budget and on time!! And, I’ve worked on almost 100 projects over the years.

So what has suddenly changed so that (again, predominantly) men can claim that buying “X” tool or learning to code in “Y” language will solve all of our software implementation problems. Well, I’ve got news for you – every new piece of technology brings with it it’s own risks and challenges. If test automation tools were going to have a major impact on our capability to deliver software projects on time and on budget don’t you think we’ve had long enough now (it’s been over 40 years since I wrote my first test harness) to make this happen?

And while I’ve got this head of steam going… Why does every tester suddenly think are capable of writing code? We (software testing professionals) have been upset for years by claims of “anyone can be a tester” and now we’re at it with “anyone/everyone can/should write code“. As I said, I was writing code over 40 years ago and I didn’t just sit down one day and say to myself “I think I’ll become a computer programmer”. I went through a very vigorous selection process and spent years learning how to be a competent and effective software developer. I know we didn’t have the same toolset as we have today, but we still had to write coherent and maintainable code – much of which is still in use today, I might add!!

And, back to the UBS component highlighted by Lee Hawkins…. If I had a dollar for every time I’d heard a senior manager say that “we have a test automation strategy that will save us thousands/millions on our software testing budget”, I’d be even richer than I am now!!

Software implementation projects frequently fail. Software test automation projects fail even more frequently. Why? In my humble opinion (as I said before) – because men always over-estimate their capability and under-estimate how long something will take. Add to this the inability of most people to be able to succinctly define the goals of any project and you will begin to understand why I still despair when I read/hear about the promises for the next test automation tool.

Software testing is a skilful endeavour, not something that can be easily commoditised (although I believe that one day we will be able to achieve some basic commoditisation). Replacing software testers with software tools is a fools errand. Assisting software testers by providing software tools is a far more sustainable outcome.

In summary – writing AND testing software is not a trivial undertaking, so why do we trivialise strategies to perform them? If you want to reduce your software tester costs, employ the best possible testers you can find, not the cheapest. If you want to automate software development processes focus on the tasks that require least intellectual capability. If you want to run a world-class software testing capability employ the people with the most battle scars, not the fresh (out of uni) drones that will work twenty hours a day, never questioning what you tell them to do. And, don’t get me started on sending your software overseas to the cheapest labour markets to archive better bang for buck….

Dateline: Melbourne, Tuesday April 26, 2106