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

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

Employees are People Too

What is this obsession that (far too many) businesses have with pushing their employees to the point of mental and physical exhaustion?

What sort of society have we created where people are encouraged to work 18 hours straight, without a break, just so the company we work for can turn a profit?

What sort of culture promotes profit over people?

I can tell you categorically, from very personal experience, that a business that puts profits before it’s people and encourages self-sacrifice is a business that will not last very long. Creating a business that truly supports it’s people, by mandating a balanced lifestyle of work, leisure and family, is a business that will thrive and remain successful. The true value of any business is it’s people, not it’s image or product. You can have a fantastic product, but if you treat your people like cannon fodder then you will have a short-lived business.

I’ve seen far too many people reduced to shrivelling wrecks because they have been put under unnecessary levels of pressure to produce an outcome (at all costs). How does the culture within a business get to a point where “toughness” is encouraged and “sensitivity” and “humility” are frowned upon? I’ve lost count of the number of times I’ve heard and/or seen the words “sensitive” and “emotional” used as negatives when describing someone’s personality. Since when did showing empathy become a negative?

As a Business and Technology Consultant for most of my life, I’ve been inside hundreds of organisations (from mega-businesses like IBM and CapGemini to small high street shops) and I can assure you that if you mistreat your people you will struggle to maintain a viable business. A simple gesture like an arm around a shoulder is very welcome in a good business, but is seen as harassment in a poor one. A word of encouragement is seen as supportive in a good business, but unnecessary in a poor one.

We need to encourage everyone to speak up (not put up) when they need support. We need to highlight and shame those businesses that encourage ugly and demeaning behaviour. We need to ensure that empathic businesses are recognised for what they are.

Humanity is supposed to set us apart from the rest of the animal kingdom. Unfortunately, I see far too little humanity and far to much animal cunning in today’s business world. I, for one, am going to start highlighting and shaming businesses that lack humanity and discourage a balanced lifestyle. I may not change the world today, but maybe I can start a movement towards true caring and understanding throughout the business world.

If you work for a company that treats you inhumanely, LEAVE. If you are subjected to unnecessary pressure, seek support and guidance, THEN LEAVE. If you are harassed or bullied, write to the CEO, THEN LEAVE. Don’t rationalise. Don’t toughen up. Don’t support their ideology. There are millions of good businesses out there, you don’t have to work for a bad one.

“You may call me a dreamer, but I’m not the only one” (Lennon).

Dateline: Melbourne, Thursday January 8, 2015

Bullying – An Unacceptable Truth

Not too long ago a former colleague (let’s call her Davina) rang me while driving home from work one night. Davina called me regularly on her way home during our 12-month working relationship. However, on this particular evening Davina sounded different. Her voice was weaker than usual, she was almost whispering. She was speaking as if she was telling me a secret or apologising for something she wasn’t proud off.

That night Davina confided in me that she had just been verbally threatened and stood-over by a very prominent Sales Exec in our company. Davina is in her late thirties and has worked her way up to middle management within the IT services sector. I was so angry that this could happen in a company that I had chosen to work for. A company that (still) heavily promotes itself as a company that truly cares about it’s people.

I’ve worked in IT nearly all my life and it has been a great career for me. I’ve also spent much of that time working for a number of Consulting businesses – small boutique ones, medium sized expanding ones and enormous worldwide ones. They all have one thing in common – they have a culture that they have consciously created. The culture of an organisation is very important to me and therefore I take it very seriously when someone exhibits traits at odds with the culture I wanted to be associated with. But I digress, back to Davina…

Davina and I spent much of the next 48 hours discussing the bullying incident. As I said before, it would be a massive understatement to say I was very angry, but (get this), Davina was almost apologising for the situation and even told me that it wasn’t the first time the Sales Exec had bullied her!! I spoke to Carla in our HR department (on Davina’s behalf) regarding the process for formally complaining about bullying. I spoke to Shahid, my own Manager and to the COO of our company – all as a precursor to Davina making a formal complaint. I needed to know how I could support Davina to the best of my ability. Guess what? Davina never made that formal complaint!! Instead, less than 8 weeks later she resigned!!

I couldn’t convince her to file a formal complaint. I didn’t want to convince her to stay. I felt powerless. I was a Senior Consultant with this internationally renowned organisation. I spoke to many senior people inside the company about the incident. They all supported me (and Davina) – at least to our faces. However, nothing formal happened to the Sales Exec and I neither heard nor read anything about the incident. In fact I learned later (after I’d left the company) that the Sales Exec got a promotion and a great big bonus that year. It was as if the other Execs all closed ranks and washed the incident away. Needless to say, I also left the company soon after this incident – how could I stay any longer in a company that tolerated such acts?

Unfortunately, bullying seems an acceptable action in many parts of our society today. We see it every day in the press, on television, online – in fact all forms of media seem very adept at providing a forum for bullies. We also see it in the playground and classroom, on the sports field and even in places of worship.

Why do people find in necessary to bully? Why is one persons wishes/beliefs more valid than another – to the point that they need to use tactics that reduce another to tears, or much worse, suicide? I wrote last year about why Test Analysts no longer want to become Test Managers and this is one of the reasons – Test Managers regularly get bullied into making decisions they don’t want to make. I know too many Test Managers who have gone on stress leave due to bullying and undermining. We have to change behaviours so that people feel safe to disagree with each other without fear of reprisals or vendettas (sub-forms of bullying in my book).

Unfortunately, I was bullied several times when I was a kid. If they were people I was going to have to spend more time with (at my school) I stood up to them and they never bothered me again. If they were people I had never met before (a random attack) I just turned the other cheek and walked away. Bullies get their power from our weaknesses and if we refuse to show weakness they have no power.

Personally, it’s been a long time since someone tried to bully or intimidate me, but that is probably because I developed a protective skin early in my life and refused to allow anyone through it. Not everyone is capable of this and these are the ones we need to support and protect the most. No one deserves to be bullied. No one deserves to be intimidated or stood over. No one has the right to impose their will forcefully on another.

I’m still incredibly angry more than two years after this incident. I despise inequality in all aspects of our lives and I despise those who use tactics like these to gain an advantage over others.

NOTE: This is a 100% true story, with only the identity of the people involved obscured to protect Davina and her family. There are many people that were witness to the weeks that followed the bullying, some of them can be proud of their part, others should be ashamed that they were so weak as to watch such an injustice play out.

Dateline: Melbourne; Tuesday January 28, 2014

25 Things I Don’t Like About Software Projects

The majority of projects that I’ve worked on over the years have been harder to deliver than they should have been. Mostly this has been down to either lack of experience within the Project Management Team (generally because of poor stakeholder management) and the unrealistic expectations of the client. These two factors are closely linked, but are by no means the only reasons for failure (or near failure). In fact, I’ve only worked on what I would consider a “failed project” on one occasion and that was when I was the Project Manager and I pulled the plug because the software company delivering the (packaged) solution lied to the client (and the rest of the project team) about the capability of their product. Basically, they sold the client vapour-ware and expected the client to pay for the development – we called them out and they huffed and puffed until even they admitted their original delivery dates were many months later than they had been promising.

So, why am I writing about things “I don’t like” when I’ve loved the cut and thrust of project life my entire career? Because I see far too much waste on projects. Waste of money. Waste of talent. Waste of time. Waste of oxygen… etc. etc. Sadly, this list could be far longer….

I don’t like: People who spin the progress of the project (spin is code for lying)
I don’t like: Egos running projects
I don’t like: Writing reports that no one will read, but the PMO insist must be written
I don’t like: Attending meetings that could be replaced by a Progress Report
I don’t like: Being told that the code is 99% complete (again)
I don’t like: Requirements that can’t be linked to a Deliverable
I don’t like: Software Releases that are not accompanied by Release Notes
I don’t like: People who email me when they sit right next to me
I don’t like: Software fixes that fix the symptom, but not the root cause
I don’t like: Project politics – more time is wasted on politics than any other single item (and it doesn’t even have a project code for me to charge my time to!)
I don’t like: lunchtime meetings – I need a break and lunchtime meetings give me indigestion
I don’t like: 9am triage meetings – they distract people from the real priorities of the day
I don’t like: Being controlled or manipulated
I don’t like: Broken promises
I don’t like: Project Managers who tell me someone in my team is upsetting the Development Team Leader (especially if I didn’t get to witness the fun)
I don’t like: Smart-asses who deflect issues and risks to other teams just before the weekly project review board sits
I don’t like: Unclear ownership of requirements and/or solutions
I don’t like: Being told that my team is having too much fun (especially when I’m not with them)
I don’t like: People who come to triage meetings unprepared
I don’t like: Being on the critical path for the project
I don’t like: Asking my team to work the weekend because someone doesn’t know how to manage a project plan
I don’t like: Schmoozing the client
I don’t like: Being given an end date, but still having to provide an estimate to prove that we can make that end date
I don’t like: Counting test cases
I don’t like: Not having enough Test environments to do my job properly

As always, please feel free to add to this list….

Dateline: Wednesday July 3, 2013

25 Mantras That Will Make You A Happier Tester

In my experience there are many challenges in the daily life of a Test team and this can lead to frustration and even stress. So, in order to make your day a little less traumatic, post this list of mantras above your desk (or create your own version) and I guarantee your day will pass more harmoniously.

I accept that some of the Requirements will not be perfect
I accept that the Developers have time constraints like everyone else
I accept that our Test Environments will not be ready on time
I accept that our deadlines will be changed
I accept that the Users will change their minds
I accept that there will be more bugs in the latest software release than I anticipated
I accept that the subject matter experts will not be available when I want to see them
I accept that the Triage meeting will take longer than I hoped
I accept that the Project Manager will not understand why my testing is taking so long
I accept that the fixes I was expecting today did not make the latest software release
I accept that none of the Users will know how to define Acceptance Criteria
I accept that the latest software build will arrive at 4pm instead of 8am
I accept that I will have to cull some of my test cases to meet the schedule
I accept that some of my bug reports will be rejected as “features” or “un-reproducible”
I accept that my Performance Testing will start late due to an unstable code base
I accept that someone outside the Test team will estimate my Testing window
I accept that the PMO will want to know how many Test Cases I will run today
I accept the concept of Groundhog Day – I have to enter my Day 1 tests for the fourth time this week!!
I accept that no matter how much planning and preparation I do, my first test will fail
I accept that my Test Data will be the previous version
I accept that there will not be enough time to check all the Batch Cycle results before the next online input day starts
I accept that I cannot re-create the Sev 1 bug in front of the Development Manager
I accept that I will be judged by how many bugs I find, not how many I prevent
I accept that the offshore team will misunderstand even the simplest instructions
I accept that I will also make mistakes – I must not be too harsh on myself…

Remember to breath and smile

Do Testers Really Need Coding Skills?

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

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

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

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

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

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

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

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

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

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

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

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

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