I'm Paul and I'm a Failure (and it's ok!)

Every day I make one silly mistake. Be that misreading some acceptance criteria or use case, setting something to the wrong value in JIRA so that it doesn't appear in a bug report, forgetting to send a document to someone, missing my train stop on the way home, accidentally pulling out my wife's computer's power cable when disconnecting my own laptop, the large number of times I wrote a tweet that in retrospect I shouldn't have...

My life in IT has had a few pretty startling incidents of backing a losing horse. The time when as test lead I fully and excitedly backed my superior's decision to solve our automation problems by buying a licence for HP QTP for tens of thousands of dollars (buying into the logic that spending lots of money of a tool shows undying commitment) going gung ho at creating automated tests in it (my team of three being the only team to do so). When my superior left and it was sensibly decided by the tech management that we would save our money and move to Selenium, my team lost its entire automation suite overnight. I couldn't argue - it was totally the right decision.

Or the time when due to my lack of experience in development, knowledge of the relative benefits of a breadth-first search and willingness to ask for help the recursive database abstraction layer I wrote took days instead of tens of minutes to run (or more often crashed due to an out of memory error - no mean feat in a garbage collection language like C# !)  and caused severe delays to a product release. The fallout from that shattered my belief in my own programming ability for years, but I got over it slowly.

Or the time when I managed to break a database migration system I was coding a multilingual interface for due to the fact that one of the lines I (clearly in an unthinking fashion) translated into French was actually a SQL statement.

Why do I mention these potentially career-limiting paragraphs in my blog? Because whilst I suffer from self belief issues as much as the next person, I don't feel ashamed of the mistakes I made (and occasionally still do), have got over the need to be a perfectionist and slowly recognised them as opportunities for learning and self reflection. Only the most privileged and least willing to take risk of us sail through life without failing at something.

Yet when I read the blogs of some of the other testers and thought leaders in this field (not that I would ever call myself a thought leader in anything), I am unsettled by the lack of humility or mention of the hard lessons behind the advice they give. Of course we have careers to protect, conferences to speak at and consulting gigs to apply for, however none of us were great IT consultants, devs and testers out of the womb. Not One Of Us. Rarely is a career a perfect and graceful trajectory from school, university via junior to senior. We all have mistakes we have made (some of us may well have been fired from jobs and had to bounce back) and opportunities to learn, so why don't we write about them, or talk about them at conferences, or mention them on Twitter?

Why aren't we more tolerant of the mistakes our colleagues, managers or staff make? Do we think we are above them? I once had a boss whose lack of tolerance of perfect work (or for that matter, temper) was legendary. I once heard him shout "I don't pay you to make mistakes!" Was he devoid of errors himself? Not at all.

Was his team a perfectly oiled machine as a result? Of course not, and most hated him. High performance doesn't come about through bullying and threatening people. He achieved nothing but probably high blood pressure. I have seen other attitudes in teams I have worked with that, whilst they are not quite as aggressive or extreme, were no less haughty.

Let's calm down and appreciate our fallibility. Admit our errors. State what we learned in the context of how we learned them. Let's be more tolerant of the honest failures of those work with. That is the only way we will receive forgiveness for our faults in return.

On Testing Technocrats

The agile manifesto, written in 2001, states as one of its aims -

 "Individuals and interactions over processes and tools"

It is hard to imagine how in an agile team, where stakeholders, product managers, developers, testers, BAs and other groups work so closely together and much knowledge is tacit and undocumented, the above aim could possibly be ignored.

Software is ultimately used by people to implement solutions to problems people suffer from. It is created by people. The use cases and requirements that developers implement and testers test against are created by someone to reflect someone's (or some people's) wishes and needs. Testers test to find issues that we hope will never be discovered by people whose problems the software under test is built to solve.

...Which makes me annoyed about the idea that development/test teams can automate everything. The problems that bad software can cause for people are many and varied and the numbers and kinds of ways that a non-trivial application may fail are far greater, often more subjective than we can possibly plan for in advance. Requirements and specifications have subtle holes and areas of tacit knowledge that risk creating a product that does a wonderful job of something people don't actually want.

I am a big fan of test automation in its rightful place. As a regression tool it frees the tester from hours of tedious and often unfruitful checks to concentrate on those areas that require more exploration, analysis and thinking. It provides stubs and mocks so that the developer and tester can continue their work without the full integrated system being ready or available. It creates reams of test data of whatever attribute is necessary so that we can continue our work without laborious setup. It helps us perform checks with multitudes of simulated users to discern areas of poor performance. For all of the above however it doesn't replace the thinking mind of a competent test analyst. The kind who is adept at putting him or herself in the frame of the user, with all the complexities this involves.

But some of us feel that we can automate all of this away for 100% test coverage by automation, or that some future AI will make all non-automated test approaches redundant (not convinced that this will ever happen). I wonder, is it all about cost-cutting? The bottom line?

Or is there a type of person who thinks that the ambiguous and complex can be completely reduced to a set of checks and algorithms? That the human dimension, the outlook that human beings provide, can be abstracted away by technology? That what people see as quality can be reduced to a set of Yes and No answers. We hit the button, stand back and like the great tech sausage factory, we pump something in, our list of deviations comes out. Rinse and repeat with a few fixes and we get quality at the end...

I call these types the testing technocrats. By reducing our work to purely algorithms and checks to be done by machines - and quashing the thinking factor - they reduce the wishes and concerns of the users of our products to exactly that.

All in the hope of getting releases out faster, saving a bit of money and not to have to deal with the complex findings that a thinking human tester provides. This has been called out as wrong many times but often to deaf ears.

Test automation is an amazing thing that lets us achieve great efficiencies. It is not a replacement for the thinking human element. As testers we should be taking every effort to continue argue against those who believe it is.

10 minute blog - Our ideas don't exist in a vacuum

(The first in a series of very short, regular articles, no more than 10 minutes in conception and completion, fairly whimsical in nature and an exercise in  keeping in the habit of writing regularly and getting over short writer's blocks).

There is a school of thought that says that ideas come out of quiet and reflection. Ever since Siddhartha Gautama sat beside a tree, meditated and became Buddha, we think that we can quietly structure great ideas from base principles. Maybe if you are a philosophical genius, apart from that I don't believe a word of it.

In the last few months, as some have probably noticed, I have spent a fairly large (non-work hours if my boss is reading this 0:-) ) time on Twitter, reading and tweeting in the various testing threads and chats. I really enjoy doing it. I'm not sure I add much to the debate - I am anything but an expert or guru in testing - however if I didn't do it then I would struggle to have any ideas to write about. This blog would die a quiet death. Very few people will come up with a truly original idea - most articles are just variations on a theme - however the best ideas you will see these days are formed in and survive the cauldron of debate.

How can we risk our ideas being repudiated, shot down, publicly ridiculed, called out for BS? I don't think we can avoid it. Many of my ideas have been shot down or ignored - and that's fine because on retrospect some of them were shit anyway. However the alternative is not saying anything, and you miss all of the shots you don't take.