Fear of Failure, Lure of Success

Why is it that so many people are driven by the fear of failure, rather than the lure of success? Is it because there is a stigma attached to failure to the point that we want to avoid failure at all costs? Is it because success seems elusive to so many of us? And what is success anyway?

Success for me isn’t momentary or transient, it’s an ongoing paradigm. It’s a state of grace. If I take a sporting analogy, it’s winning a competition that lasts 9 months (against 19 other teams), rather than winning a single (albeit important) game. Here is my take on my some of my successes and a few of my failures (and why, with hindsight, the failures don’t matter).

Younger Me: In high school I wanted so much to play for the 1st XI at soccer and cricket, but no matter how hard I trained, I was never quite skilful enough. At the same time I discovered that I could run (fast) and that I also had excellent stamina; however, running wasn’t cool in school, so I kept on trying out for the soccer and cricket teams and eventually, in my final year, became a fringe player, getting a game when others were injured or sick.

Wiser Me: I never played cricket again after high school, but I did play soccer (and for a few years 3 times each weekend) until a few years ago. The wiser me reflects that I won far more trophies in the last 5 years of my soccer “career” than I did in the previous 30!!! The biggest success, in hindsight though, was the camaraderie and friendships I forged with the hundreds of guys I played with. On the running front, I have completed five marathons and about 20 half marathons and these days I employ my fitness and stamina on a daily basis playing tennis, badminton and squash while also riding my bike as often as I can. Brain and body fitness go hand in hand in my book.

Younger Me: When I left high school University wasn’t really an option as my academic achievements weren’t consistent enough – great at Maths and Geography, crap at science and languages!! I fantasised that if I’d lived in the USA I would have gained an athletics scholarship to a top Uni, but it was a fantasy! Somehow I won a national writing competition in my final year at high school, but in hindsight, I think the rest of my final year suffered because of the 3 months I focused on that competition.

Wiser Me: As far as I can tell my lack of a University degree hasn’t damaged my career, but I think that is more of a reflection of the time I left high school (the early ’70s) than any monumental effort on my part. I did manage my career strategically but also got a break early when I lucked onto a job as a computer operator in 1971 and from there I gained access to programming, business analysis and latterly software testing. The key decisions were to focus on the finance industry in the mid ’80s, specialise in software testing in the mid ’90s and move business sectors every two years from early 2000. If I hadn’t taken a strategic approach to my career I would have drifted along, like many of my early contemporaries, and achieved far less.

Younger Me: I was desperate to become a manager in my late 20s and early 30s, but opportunities alluded me. I’ve never been good at taking direction and this led me to take up freelancing in my late 20s in an effort to have more autonomy.

Wiser Me: In hindsight, it was just as well I was into my 40s when I first managed a team, because I needed the maturity and life skills to be (what I now consider) an effective manager and (ultimately) leader. I was talking to my daughter the other day and she got her first management position in her early 20s and she’s now unhappy with many of her decisions in those early management opportunities.

Younger Me: Until my mid 30s I was ego-driven and self-centred. I wanted to prove that a young working class lad from the wrong side of the tracks could be successful if he worked hard and stayed focused on the dollar.

Wiser Me: Today I look back and note that my happiest working days are when I am working with great people who care about each other more than than they care about wealth and social standing. Once I learned to trust others, give guidance (as opposed to direction) and accept what I can directly control (ultimately, very little), I became a far better employee and a far better human being.

I am realistic about my talent, but unless I apply effort my talent is wasted. I know that I have never shirked responsibility for my actions and have worked tirelessly to achieve business outcomes, but unless I apply thought to those efforts, I’m wasting my energy.

Here are the top 10 reasons why I have achieved success…

  1. I seek out those that are smarter than me, seek to work with them and then study them
  2. I listen more than I speak
  3. I analyse data, look for patterns and work out easier ways to do things
  4. I try not to complicate stuff, simplicity is always my aim
  5. I take my time when detail is required and move quickly when it’s not
  6. I summarise information and offer insights rather than throw a myriad of detail out there
  7. I treat people as individuals
  8. I get specific when it’s appropriate
  9. I work as if I’m coming second in a race I want to win
  10. I don’t confuse popularity with success

Earlier in this post I said that my failures don’t matter. Why would I say this? Because for me failure is not an end, it’s a beginning. What I mean by this is that unless someone physically stops me from pursuing an outcome or goal I will keep trying until I succeed, I’m resilient and determined and these attributes have stood me in good stead all my working life. It is my belief that my lifelong involvement in sport has heavily influenced my ability to succeed in business as it has taught me the value of consistency and resilience.

How do you quantify your successes?

Dateline: Monday January 16 2017, Bagshot (UK)

Advertisements

Software Testing Conferences: The Why

A couple of days ago I was having a discussion with @nzben and @maaretp on Twitter regarding whether speakers should be paid (as a minimum expenses) to speak at Software Testing Conferences. During that discussion @nzben asked me how much I had (personally) spent on speaking and attending conferences during my (25) years in software testing. I thought about this for a while and came up with a figure in excess of $250k. Before you all get your calculators out, I used a very simple formula – I budget for 10 days of formal learning each year and on average over the years I’ve earned $1,000 per day (as a freelance testing consultant). When you work freelance you only get paid for your days in the office. Now I didn’t quite make 10 days every year (mainly due to heavy workloads and holidays) and I didn’t always pay large amounts to attend conferences or training events but you can see that the financial investment was significant by most people’s standards. If I had my time over I would have spent more, but that’s another story.

The reason I am writing about this today is that we (in Australia) have long been poor cousins to the rest of the world with respect to local access to thought leaders in our field and therefore I needed to travel to Europe and the USA for the majority of my (career development) needs. This has been slowly changing over the past few years with the likes of Michael Bolton and a few others visiting several times. This year we are very fortunate to have TWO major international conferences within the next few months in Sydney and Melbourne respectively. From my perspective anyone who is serious about software testing should attend at least one of these events and, if possible, both. I will definitely be attending the Melbourne event (http://www.qualitysoftware.com.au) on May 10-12 and I’m currently deciding on the Sydney event (https://www.associationforsoftwaretesting.org/conference/castx17/) that occurs February 20-21.

If you can’t steal your self away for either of these excellent events we are beginning to get traction on Software Testing Meetups around the country and as far as I am aware these are all FREE. I belong to several Meetup groups in Melbourne and get along whenever I can. The TEAM Meetup in Melbourne is very active; you can find them at http://www.testengineeringalliance.com. Also in Melbourne is STAG (Software Test Automation Group), Melbourne Software Testing Meetup and Agile Testers Melbourne. In Sydney the have (the aptly named) Sydney Testers who are one of the top five (by registrations) software testing Meetups in the world, so they must be doing something right. You can just download the Meetup App as an easy way to find stuff.

Long before the Meetup buzz began there were (Australia and NZ focused) ANZTB Special Interest Groups established and I’ve attended and spoken at several of these over the years. However, it’s been a couple of years since I attended one of these, as I’ve been banned by the ANZTB from speaking at their events after a rather silly infraction several years ago in Canberra. I’ve written about this previously, so I’m not going to harp on about it again. Their loss…..

So, there you have it, I urge you to take control of you career development by attending one of the previously mentioned Conferences or (failing that) a local Meetup as often as you can. We are not as fortunate as our European and American cousins who can attend a Conference almost weekly!!

My next Blog post will provide a list of all the 2017 Conferences in Australia and New Zealand that I think you may be interested in.

Dateline: Friday January 13 2017, Bagshot

Defect Priority v Severity: Debate No. 763

A dear friend of mine (let’s call her Cheryl – because that’s her name!), sent me a message on LinkedIn today. Here’s the central question – “If you avoid looking at IEEE or ISTQB, in your opinion, what do you think is the right description of Defect Severity v Defect Priority? Does it vary based on agile v waterfall worlds?”

It is my experience that we have been debating the concepts of Defect Priority and Severity for most of my 25+ years in software testing and I have been asked hundreds (probably thousands) of times, to define/explain/clarify etc. these terms. On top of this, as Cheryl points out, there are “standards” that define these terms also. So, in the expectation that this could be a protracted debate (which is something I’m quite comfortable with, by the way) here is what I said to Cheryl,plus my  broader  thoughts on the subject….

“Hi Cheryl, great to hear from you – Happy new Year 🙂 

My views on this question haven’t really changed over the years and I know plenty disagree but (from a triage perspective) Defect Severity is the impact on the business and/or technology capability, while Defect Priority is the impact on getting the solution out there. For me this means that in a context where external customers are the primary users, Severity is always more important, because you can’t always (perhaps even rarely) contain the impact of a high severity defect. 

It’s an interesting point you raise regarding agile v waterfall – and one I hadn’t really considered much before. My initial view is that the context within which you are working is key. I would probably say that momentum is more important in most agile contexts, but if you were working on mission critical stuff, I’d be back on Severity. I think it’s a great question regarding agile v waterfall as there are far more non-testing specific complications in play.”

So, there’s the initial discussion and here are my broader thoughts (and the context within which they live)…..

I have spent the majority of my software testing career driven by and focused on customer-centric outcomes. By this I mean that if the customer (or user, more generically) can’t use the software effectively and efficiently there’s not a lot of point in producing it in the first place. I have always been more driven by outcomes than journeys and for me the Priority of something like a defect is part of a journey, while the Severity of a defect (while possibly waxing and waning) will generally remain long after the software is released (unless there is a significant business shift). Putting it slightly more bluntly, shit will always be shit.

As I said in my response to Cheryl, the context within which we discuss and agree these things is key and there are so many contexts within which we all work and more broadly exist. Therefore, my strategic and operational solutions to introducing Defect Severity and Priority guidelines over the years have been varied; however, the bottom line for me is that we identify the impact and root cause of a defect as quickly as possible (triage) and then get it fixed within the most appropriate timeframe that our business allows. And this is where the question of agile and waterfall seeps in. The waterfall approach will more often than not mean that there is far more time for reflection and planning and I have seen the Priority and severity of defects change significantly as the various test cycles unfold. This is less likely in a more agile environment.

I think I’ve provided enough insight into my own ideas here without getting too specific or contextual. So, what is the current consensus out there. I’m eager to hear from anyone, whether they agree or disagree or want to build on or tear down my thoughts.

Dateline: Sunningdale, Thursday January 5, 2017

PS Happy New Year everyone

Testing Wars (Episode IV): The Software Tester with an Identity Crisis

So long, fair world, it is time for me to sail off into the sunset, taking with me my orthogonal array gun and retire to that beautiful corner of the Universe where old Software Testers go to die – GitHub Major… It is a sad day for me, as I have finally accepted the brutality of software development in the 21st century – there is no place for a relic such as I – the much maligned Software Tester. For several years now I have been fighting a rearguard action while under constant attack from Agilist Propaganda. And so I have decided to cut and run, while I’m still at the top of my game. I don’t want to end up like some 70’s pop idol working for peanuts in some third-rate government agency backwater, regression testing a 40-year old payroll system cobbled together using fragments of COBOL-74.

But you still have so much to offer, I hear you say….

But what shall I do and where will I be respected for my skills (and ISTQB qualifications) that I have so diligently acquired throughout my professional career? Maybe there is some far flung planet in a galaxy far, far away that still needs a bug magnet. Maybe I can join the Dojo Alliance and spend my days recording defect triage videos that will appear as a backdrop to some 22nd century Reality TV show? Maybe I’ll download the entire EuroSTAR back catalog and sun myself on a beach near the Sea of Tranquility?

Yesterday I was a Software Tester and the force was with me. Today I am too sad to face reality. Maybe next week I’ll seek inspiration from the Life of Brian and pursue a long held ambition and search for the Holy Grail of software development: the on-time, on-budget, bug-free software delivery project. A search that I fear will end like some Quentin Tarantino movie – in a pool of blood.

Dateline: Tuesday November 22, 2016

Testing Wars (Episode V): The Software Tester Strikes Back

If I believed every “Testing is Dead”, “The Tester is Dead”, “No More Testers Required” headline I’ve read in the last 12 months, I’d be dummer than a Donald Trump supporter!!! I was alive and working fervently as a Software Developer at the advent of the Tester and so I remember why this discipline came to be in the first place. We were working on ever increasingly complex IT solutions and we were trying to be all things to all men. We, as Developers, had already morphed into Analyst/Programmers and now we were morphing into Quality Assurance and Quality Control professionals. In fact, I morphed from a Developer into a Tester myself….

I don’t remember the exact day that the Software Tester came into being, but I am damn sure I won’t see the day the Software Tester died. Software is becoming more invasive in our lives every day, so to think that the risk and/or quality aspects of its production are going to decrease beggars belief. Yes, we are going through changes in the way software is delivered (this will always be the case) but the fundamentals of how this is achieved (via scientifically-based endeavours) means that the rigour through which it must be subjected will continue for the foreseeable future. I say foreseeable future because I don’t have a crystal ball.

The majority of (Tester is Dead) propaganda (and that’s what it is, dear reader) is being spread by those with agendas, supported by a significant amount of self-interest. We already have significant challenges attracting brilliant minds into our magical world of software testing, without naysayers putting extra bumps in the road and creating unwanted dead-ends.

Software Testing is an essential endeavour in our world today and will increase in importance until we improve our critical thinking skills and learn how to build software that is truly self-correcting. I have written several times over the years about the work that needs to be done so that software can fix itself, but I do not see this coming to fruition, on a commercial level, within the next 10 years. So, until that day comes, we (Software Testers) will not being going the way of the chimney sweep or the Telex operator anytime soon.

The Software Tester is ALIVE and KICKING (arse); remember, you read it here first!!

Dateline: Melbourne, Wednesday November 30 2016

Failure: A Software Tester Perspective

When I was a kid I was taught that failure was a bad thing. This was a constant and overt message I received from both my parents and my teachers. This was also later reinforced by my sports coaches and several bosses early in my career. Yet, as I have grown older, I have become more aware of the philosophy that we learn a great deal more from our failures than our successes. Leading to the belief (of many) that “failure is good”.

But, is it that simple and straightforward? I don’t think so. Neither success nor failure are black and white; in fact, in my opinion, it is generally just a matter of perspective. If I got anything less than an “A” for Maths (while I was at school) it was seen as a failure; however, if my brother, Paul, got a “B” in Maths there would be celebrations for a week!! It was about expectations and perspective. I was expected to excel at maths, while Paul was perceived to be bereft of mathematical acumen. They say that beauty is in the eye of the beholder, but I also think that failure is in the eye of the beholder. I also believe that by not setting clear goals we set ourselves up for failure.

I have been a perfectionist (with regards to my own achievements and goals) for as long as I can remember, but I believe that I am a realist when it comes to my expectations of others. I do not measure myself against others or measure them against myself and therefore I do not measure my success or failure based upon the achievements of others. This is something that I am very grateful for as I hear many people say how unhappy it makes them feel when they fail to measure up to someone else’s expectations.

As a Software Tester I expect to find failures when I am testing software. In fact, I expect to find failures in software throughout the normal course of my daily life, not just when I am actively testing it. Why is this? Because I spent almost 20 years writing software (before I changed careers and became a Tester) and instinctively know the pitfalls common within the software development life cycle (SDLC). There are literally hundreds of opportunities for failures to occur in software development, right from the concept or original idea through to the launching of the finished product. In fact, it is reasonable to assert that launching software is just the beginning of another cycle (the live cycle), where market-driven forces take over.

So, is failure in software good or bad? You’d probably say “It’s bad if it causes me to lose some money“. You’d probably say “It’s bad if it causes the loss of my arm or leg“. You’d probably say “It’s bad if it results in my car malfunctioning“. You’d also probably say “It’s bad if the power goes off when we are cooking dinner“. But I would counter these arguments by saying “It could have been far worse, if we hadn’t thought through these risks and reduced the impact“. 

When I look at the possibility of failure I do not think of it as an opposite to success, I see it as an unwanted outcome that I can mitigate via various means. Whether it is a personal or software-related goal, that I am working on, I make sure that I am very clear about what I am trying to achieve and therefore, if a failure does occur, it is because I wasn’t realistic and/or clear in my goal setting. 

My current thinking is that we need to be far clearer when we identify our needs and goals – when it comes to the development of software. We need to define and agree success at every stage of the SDLC in order that we do not carry (unacceptable) residual risk forward to the next phase and certainly not into the live state. I also believe that when people talk about personal failure they are referring to setbacks, which is a whole different ball game and probably needs to be the subject of another blog post!!

As I said before, failure is in the eye of the beholder and therefore stating categorically that it is good (or bad) to FAIL does, in itself, sets us up to FAIL.

Dateline: Melbourne, Wednesday September 28, 2016

T is for Training (My A to Z of Software Testing, Part 12)

Over the past week or so I have been doing something I’ve never done before – Housesitting for a family who have gone to Canada for their annual holiday. The Housesitting predominately involves looking after their 9-month old dog Lexi by walking her for a couple of hours a day and keeping her safe, while also looking after the house itself. The reason I am doing this is because I am in the UK for the birth of my granddaughter Heidi, who was born just a few days ago.

So, how did I get this gig and am I really qualified to do it? I’ve never been on a formal training course for dog ownership and I have actually owned my own dog for over 30 years… It’s not rocket science, but I believe you do have to fundamentally like dogs and preferably have an affinity to them; i.e. you enjoy being around them and you both respond to each other in a positive way. I love nearly all animals and generally feel at ease around them; exceptions include the obvious ones like crocs and alligators, poisonous snakes, nasty looking spiders and sharks – pretty much anything else is cool in my book. And so it goes with software testing…. there are some very dangerous animals within the software testing world – most of them loiter on social media, so it’s not too hard to avoid them!!

But let’s get back to the Training aspect of my story. In my opinion, I can be a perfectly good dog carer/walker etc. because I grew up with a dog in our house and I underwent many years of “on the job” training. I’ve also had refresher sessions over the years caring for family and friends dogs, so I believe that my lack of a piece of paper stating that I am a “certified dog carer” is no impediment to my credentials as a professional dog carer. I know there are some of you out there who probably think I’m a bit of a “fly by night” cowboy for taking this approach, but I truly believe that on the job experience and a true passion for what I do makes me more qualified than those types who have been to the right schools, read the requisite books or attended a certified training course.

Likewise, I have worked with hundreds of proficient Testers who have never been subjected to ANY formal training in the art of software testing. Now, this doesn’t mean they haven’t trained or practiced their art either. Training can take many forms and my preferred method is to discuss a new skill and then practice it in the real world and this is what I encourage my teams to do. Learn together, train together, practice together and challenge each other to be better than they were previously. I really like the Ministry of Testing #30daysoftesting challenge that ran through July, there was no prerequisites or prior learning just a set of software testing challenges that anyone could attempt. AND the great thing (for me) was that folks were encouraged to share their work.

My personal training regime is probably more severe than most people, as I have challenged myself thousands of times throughout my life to become better at pretty much everything I do – and this obviously includes software testing. I still work out almost every day to perfect my testing skills and writing this Blog is one way of doing this. Writing about some aspect of an activity forces me to think more deeply about it and analyse why I do things in a certain way. It forces me to challenge my own thinking and seek out others thinking on the same topic. This method has worked for me in all aspects of my life and there are many cross-over advantages between topics. For example, the way I train for my cycling, choosing different types of terrain (sometimes steep and difficult, sometimes fast and flat) gives me ideas on what sort of skills to develop as a Tester, including over what length of time I should dedicate to a specific skill or activity. The scheduling of specific challenges to fit in with day to day family life is another cross-over positive. Learning when to push and when to rest are among other benefits. By the way… I don’t have a professional qualification in cycling either!!

Training for anything can be arduous and tiring but the benefits endure when the chips are down and the going gets tough. My motto –
Train hard, work hard, play hard; make your worst better than everyone else’s best“.

Dateline: Bagshot, Thursday August 4 2016