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

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

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!!