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

Diversity Rant Part 2 – Another Facepalm…

A few weeks ago I wrote a short rant about a local conference “TConf 2016” and the lack of diversity in their one-day software testing program. As the conference is scheduled for tomorrow, I thought I’d check out the website for any updates. And guess what? The program has changed. And guess what? They now have a (token) female on the program.

One out of eleven speakers is still a very poor effort though, folks. It also smacks of an afterthought.

But there’s more! The conference also purports to support “WWCode” (Women Who Code). You must be joking folks. One out of eleven speakers is female and you highlight on your website that you support WWCode – get outta town!!

But, I am not giving up on these poor misguided folks. I am hereby offering my extensive involvement in (successful) international conferences and providing an olive branch for this and future events. If you are serious about running the best event you possibly can, call me anytime. I’m based in Melbourne. I have the time and the inclination. I would happily help with a post-event review (which I’m sure you’ll conduct, being quality-focused professionals) and any future event planning.

Oh yeah, and good luck tomorrow.

Dateline: Melbourne, Thursday November 17 2016

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