Diversity – Still a dream in software testing?

I was browsing my LinkedIn feed yesterday and noticed that one of my connections was recommending attending a local software testing conference (he has already signed up). It’s nothing major, just a small local event called TConf 2016 (Everything about Software Quality) taking place in Melbourne next month. So, I thought I’d check it out and see if it might be worth attending – after all, it’s always good to support local initiatives AND it looks a steal at $49 (for 9 talks over one day) AND it’s fully catered. Where do I sign up?

So, who’s speaking and what are they talking about? The opening keynote is by a guy from SEEK talking about “Refactoring a quality culture for continuous delivery”. This is followed by Morning Tea and then a guy talking about “A big data testing strategy to improve quality data” and then another guy talking about “Mobile application testing using Amazon Device Farm”.

After lunch we get a guy talking about “Performance testing at REA” and then another guy talking about “Continuous visual integration”. This is followed by Afternoon Tea and another guy talking about “Automated security testing for continuous delivery”. To close out the day we get another guy talking about “The case for consumer-driven contracts” AND, last but not least, another guy talking about “Testing insights: in the fast paced technology world of apps”.

In summary: 9 speakers. ALL MALE. 7 of them 30/40-ish caucasian.

As I wrote on LinkedIn in response to the recommendation – #Facepalm

To quote from the conference website – “We created TConf to bring industry leaders together, to share the challenges and solutions to complex quality problems in the industry. We have a strong desire to advance the Quality function. We believe in the importance of these fundamentals, a good software tester is also a good engineer, communicator, pragmatic thinker and above all problem solver“. It also appears that the majority of good software testers are caucasian males in their mid-thirties.

Where is the balance and diversity in this program?

I’ve got nothing against any of the individuals speaking, but I do have a big issue with the organisers. How many women did you invite to speak? How many turned you down? Do you care how many women attend your conference?

End of rant….

Postscript: Just in case any of you are wondering, I (a mature caucasian male) will NOT be attending NOR recommending anyone else attend this conference, even at $49 for a full day I consider this to be a very poor investment of my time and money.

Dateline: Melbourne, Friday October 21 2016

The Why and The How

For me, everything begins with the Why and is followed by the How… 

Why did I (a successful software developer with over 15 years experience) become a Software Tester?

No, it wasn’t because I wrote crap software and therefore had to test the shit out of it before anyone also saw it!! It was, primarily, because I got bored coding the solutions and wanted to spend more time looking at the problems. I later discovered that it was far harder seeking out (potential) problems than writing/amending code – and this kept me interested… for 25 years (and counting).

How did I become a Software Tester?

I began by using the techniques that I learned while debugging my own code and from there expanded into Integration Testing (between discreet programs), System Testing, Integration Testing (between systems) and beyond. Context: you have to remember that there was no (accessible) internet in the mid 1980’s and therefore the only effective way to learn was (for the first 4-5 years) by trial and error, then I sought out training courses and books (thank you Dot Graham) and then I began attending the EuroSTAR conferences. I know it’s easy to say “you’re lucky, because in my day…”, but it was incredibly difficult to forge ideas and push boundaries when you didn’t even know the questions you needed to ask, let alone find the answers!!

Why am I dismayed that so many Testers want to code?

I have never understood the current trend for Software Testers to want to code. Even with my 15+ years as a developer (in fact, probably as a result of it) I never thought to go back and write code once I became a hands-on Tester. WHY? Because, I trusted the specialists to write any software I needed (to support my manual tests). I believe, the basis upon which we originally created a distinction between DEV and TEST (the activities and the roles) is even more important today than it was in the 1980’s, when I first became a Software Tester. Technology is the most complex it has ever been and therefore we need to keep a clear distinction between DEV and TEST.

How do I remain an effective software tester if I don’t code?

I focus on what differentiates a human from a machine. I understand context and ask questions, while a machine can only follow commands. I can remember nuances regarding what was difficult to test last time I was in the vicinity of the system under test. I can explore, while a machine has a defined route. I can change priorities at a moments notice, while a machine awaits more information. I use instinct, while a machine…. I think you get my drift – I am a human using technology to assist me with my software testing goals, not a machine awaiting guidance etc.

Why do egos get in the way of outcomes?

I believe that developing software is hard enough without letting egos get in the way. There is always more than one way to achieve an outcome and generally the simplest way is best (Einstein certainly believed so). So, why do we waste countless hours, days, weeks, months (and sometimes years) debating WHY THIS WAY IS BETTER THAN THAT? The most important aspect of any product is that it meets the need of someone (not everyone) that matters* and therefore everything else comes second and therefore doesn’t matter… If we took this approach (more often) budget/schedule overruns would be far less prevalent.

How did I get rid of ego-driven actions?

About 20 years ago (in my late 30’s / early 40’s) I began to question how I did stuff and what prevented me being as successful as I expected to be. I came to the conclusion that the root cause was the impact of my ego. Since that time I have worked tirelessly to reduce the impact of (my) ego (and the ego of others) on both my professional and personal life. Don’t think this is an easy task, because it isn’t. Learning to let go and trust others isn’t easy – especially when you’re a perfectionist, as I am. However, as with all habits, focus and practice eventually lead to change and better outcomes. Being a sportsman all my life has taught me that nothing beats practice and I still practice selflessness, empathy and compassion every day.

Why do organisations look for cheap(er) software testing solutions?

I believe that generally in life we get what we pay for. And, it’s no different when it comes to testing software. If you value your organisations reputation WHY would you hand the validation and verification of software (upon which your organisation probably relies to function on a day to day basis) over to another organisation – whose reputation is almost certainly far less important than yours? In a similar vein, why would you also allow another organisation to choose how experienced (or not) the folks are who test your software?

How do I deal with the “You’re Testing is too expensive” accusation?

My first response to this accusation is always – “Expensive? Compared to what?“. As I have said before, context is (almost) everything. If you are Volkswagen and you manipulate your test results, testing can be VERY expensive!! My context has typically been in the commercial software field – banks, utilities, logistics, telecoms etc. and therefore my approach has always been to understand the underlying business risks and quality expectations in order to determine the level of rigour required for software testing. I frame my proposals along the lines of…. “If we spend this much time and money (on testing) this is the likely outcome”. This approach has (in 99% of cases) led to a successful outcomes. The other 1%? Well, there’s always one smart-arse in the room!!

Why do I still care so much (after over 40 years in IT) about the quality of software?

I believe that if something is worth doing, it is worth doing to the best of my ability. I also believe that, due to the proliferation of software in our lives today, that the quality of software will continue to grow in importance and, as a result of this, the craft of software testing needs to continue to grow as an independent and scientifically-based occupation.

How do I maintain my passion for the craft of Software Testing?

I have a passion for causes and I decided long ago that quality was something worth fighting for. I have always admired the beauty of the journey, as much as the eventual destination (sometimes the journey is far more fulfilling). As a sports lover, I have always believed that the lead up to a goal is far more interesting than the goal itself. There are a million routes to reach a destination and I’ll, more often than not, take the route that is most satisfying – sometimes this is the quickest and most efficient route, but sometimes not!! This sometimes leads to differences in philosophy and I am quite comfortable taking my passion elsewhere. How do I justify this approach? My integrity prevents me from bending too far when it comes to quality outcomes….

Dateline: Melbourne, Friday October 14 2106

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

You can’t Build Quality into Software BUT you can Keep Shit Out!!

For far too long now there have been a number of (marketing-driven) mantras along the lines of “building quality into software”. I even worked for a company that built a whole strategy around the concept, they called it “shift left”.

I’ve never been a big fan of hyperbole, especially around the promise of software, and so when the execs are looking for a “point of difference” and some bright spark (usually from marketing) comes up with “let’s say we build quality in from Day 1” my first reaction is “HOW DO YOU DO THAT?”.

As someone who wrote software for over 20 years, I can tell you that our main focus (as Developers) was meeting deadlines and this meant keeping things simple and not getting too clever. What this translated into was stuff like this:

  • Understand the main requirements and filter out frivolous requests for features that are not necessary
  • Understand how the software is going to be used in order that misuse can be prevented via the software, rather than the user or non-human interface
  • Understand the context within which the software will be used and then ensure its security within that domain
  • Understand the user base in order that the software be tailored for user level(s) of maturity
  • Understand the voracity of the data that is to be presented and ensure that it is good enough to enter our domain (by rejecting the rest)

This is not an exhaustive list, but it gives you an idea of the concept of “keeping shit out”, while it was certainly not “building quality in”. We could discuss concepts like “static analysis” here and there is certainly a major advantage to taking this approach, but I still see this as a “keeping shit out” tool as opposed to a “building quality in” tool.

In my book, quality is quite esoteric, in that it is in the eye of the beholder. Whereas, most people recognise shit quite easily. Most of us know what we DON’T want, but find it much harder to define what we DO want, so it is no wonder that the marketers focus on something that is far harder to define – it helps keep them in a job!!

If you want me to develop an App for your personal banking it will definitely cost you more and take me longer than if you want an App to keep you informed about the weather or an App that finds your missing Pokemon!! However, in each case they would still be delivered to exacting standards that met user expectations. And, in each case, I would still focus on “keeping shit out” not “how can I build quality in”.

Food for thought??

Dateline: Melbourne, Thursday September 8, 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

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