Change Agent

I was re-reading my old blogs from a few years back and realised that my views have changed a lot since then.

In fact, when I look back to several years ago I realise my views have dramatically changed. I’ve shifted my thoughts and ideas by a significant distance.

The reason for these changes are personal decisions (goals and ambitions), some were chance encounters (we could call it serendipity) and others were opportunities I sought out myself. Furthermore my blogging, writing and speaking at conferences has also widened my awareness field. I’m meeting more people and learning new tricks.

That’s not to say that these old ideas/experiences and ways of working were invaluable or wrong. They were moments in time, they were valuable experience, they have made me who I am today and they were most likely the best choice at that time with the information I had available. I am grateful for all of my opportunities and the people I have met. I truly am.


But I will change. In fact, I must keep changing.
•    When I started out in Testing I believed everything was controlled by a master test plan, some predefined test cases and a standard set of expected measurements.
•    I worked for a forward thinking Test Manager who bought the whole team a copy of “Testing Computer Software” by Cem Kaner.
•    I was “encouraged” to sit my ISTQB foundation exam which opened my eyes to the standardisation of talented people.
•    I was given a great opportunity to lead teams.
•    I was encouraged to blog about Testing, attend conferences and write for trade magazines.
•    I started speaking at conferences.
•    I got to speak face to face with well known Testing practitioners (they are very approachable).
•    I got a massively lucky break to stumble across the Software Testing Club and finally end up working alongside Rosie and team.
•    I got free reign of my Testing to ensure delighted customers rather than numbers in a spreadsheet.
•    I learned more and more about Exploratory Testing.
•    I re-found my passion for social sciences like communication and ethnography which I have managed to bring to my testing world.
•    I was also lucky enough to find a reader base for this blog and my other writing through The Software Testing Club (a big thanks to you all).
•    But most important of all; my experience, work, friends, family, network, goals and chance encounters have all changed my mind and my views as I journeyed through my testing career.

This post is beginning to sound very self centred, but there is a point to all of this.

I strongly believe in the human capacity for change. I believe we shouldn’t write someone off without exploring what we can learn from each other. I believe we should never assume we know it all and never assume other people know less than we do. I think we need to appreciate that people can and will change.I believe that people will change. That they can change. And that over time we must all change.

And if our insights and views on testing really haven’t changed in the last 10 years, then we probably need to look closer at why not.


The Impossible Job

The Impossible Job


I’ve been recruiting recently and whilst researching the typical job ads and roles available here in the UK for style and content I noticed a worrying trend. Well, to be honest I noticed several worrying trends but don’t get me started on why certification should NOT appear as the number 1 requirement for any tester…


The trend I noticed was the impossible job.


The impossible job requires you to predict the future.
“Test plans should be prepared in advanced to cover all eventualities”
“Your Test Plan should explain in detail what will and will not be tested prior to testing, to ensure no defects escape to live”
“Your test cases will cover all user interactions”
“Your ability to release zero defect software will be exceptional”


The impossible job requires you to do exhaustive testing.
“No defects will be released to live”
“You must cover all features and functions in full depth”
“You will be expected to provide complete test coverage”
“Your ability to release zero defect software will be exceptional”

The impossible job requires you to be the Quality Control.
“The product quality will be exceptional because of your expert testing ability”
“The product quality issues will be solved before release through excellent testing”
“You will ensure that the product is of exceptional quality”
“Your ability to release zero defect software will be exceptional”

The impossible job requires you to be the master of everything.
“You will be an experienced Test Manager, expert Programmer, talented Performance Test Engineer and amazingly experienced electrician”
“You will be an experienced test lead, have lead large and small teams, have every certification possible, be well verses in C#, Java, Python, Ruby, and C++ whilst also being a talented performance tester and capable of seriously great exploratory testing. You will also be required to help out on support, do sales pitches, prepare legal paperwork, set up and configure the internal IT infrastructure and have some knowledge of agile principles”
“Your ability to release zero defect software will be exceptional”


Always be wary of the impossible Job.


(Disclaimer : The text in speech marks was paraphrased and didn’t exist in this form in the original job adverts – I may also have made some of it up)
(Disclaimer : From first hand experience, you don’t need to set impossible job roles to get the right people)
(Thought : Could the impossible job be the cause of misused metrics…or the effect of misused metrics…or both?)

60 Day Proof

Everytime you write something down think about making that writing 60 day proof.


The 60 day proof concept goes something like this:


“If I were to re-read what I wrote in 60 days time, would I know what it meant and would it still make sense?”


I’ve spent the last few years fine tuning my own writing based around this simple rule with lots of success. But also with lots of gaps and holes and at times I simply forget. I first encountered this 60 day proof idea in Michael Bernstein’s thesis on scrapnotes (an excellent read for people who make lots of notes) in which a subject he was observing made all of his/her notes sixty days proof. I was struck with how simple, yet powerful, this concept could be when applied to my everyday work, from note taking to defect reporting. It embodies my promotion of Purpose, Audience and Context principles for communication.


For everything I wrote down I tried my hardest to use this principle. This covered emails, notes, messages and any other form of communication I could…and it made a massive difference.


Adopting this simple concept meant I struggled less with ambigous notes and reports, had fewer of those “give me a minute to get my head around it” moments and it also made my communication even easier to understand by other people.

I still find notes in my pad that make little or no sense. Typically one time reference notes such as IP Addresses, temporary snippets of product information, blog ideas and key words that trigger thoughts in my head. But on the whole I’ve really started to take the care and time to write my notes with recall as a clear objective or purpose. It’s made a huge difference to my defect reporting as it’s made me think about making these defect reports as readable, understandable and future proof as possible.


Why not give it a go and see if it changes your writing. It may be you write your notes, emails, reports and defect reports with clarity in mind, but I thought the same also. Only on inspecting my writing did I find plenty of areas of improvement. Writing is a process of continous improvement and the 60 day proof concept, when considered constantly, has made a marked difference to my testing world. Let me know if you use a similar process or whether this concept might work for you too.

Disturb the peace

I subscribe to a very excellent blog called “Manage Your Writing“. And today’s absolute gem of a post included a quote which hit home with me. The quote could almost have been written for testers.


In her book Leadership and the New Science, Margaret J. Wheatley wrote:

For a system to remain alive, for the universe to move onward, information must be continually generated. If there is nothing new, or if the information that exists merely confirms what is, then the result will be death. Isolated systems wind down and decay, victims of the law of entropy. The fuel of life is new information–novelty–ordered into new structures. We need to have information coursing through our systems, disturbing the peace, imbuing everything it touches with new life.


“We need to have information coursing through our systems, disturbing the peace, imbuing everything it touches with new life.” <– I love that line.


I’ve been accused of “disturbing the peace” of projects in the past. I’ve been accused of generating too much information, too many bugs, too many risks, too many…..yada yada. But could that be the essence of what testers do? We move projects forward by generating information, feedback and insights for the stakeholders? Isn’t it our jobs to seek out new information, to NOT merely confirm X is X, to push boundaries of learning and information gathering? Yes, No, Maybe?