The other side of comedy ...

There is a scene I remember well from The Birdcage - where Republican politician Gene Hackman is forced to escape the paparazzi, and the only option is to pretend to be a drag queen.  Oh the indignity - at the time I thought it was pretty hilarious ...

It's not alone - Tootsie, Mrs Doubtfire, Old Mother Riley, Nuns On The Run, Some Like It Hot.  Men dressed up as women is big comedy.

Then I made friends with a transexual woman named Violet, and I realised it wasn't funny at all.

How do you know you are male, or are female?  Is it because it was recorded on your birth certificate?  If it because you look between your legs when you're in the shower, and see "the appropriate bit" that reminds you what gender you are?

Although everyone has their different stories, transexuals are people who look at their birth certificate, and the parts between their legs.  And it doesn't add up - they just don't feel that way.  In the time since I got to know Violet, she's not the only transexual friend I've ended up with.  But she certainly opened my eyes to the struggle that goes with trying to follow your true identity.

The common story I hear though is that trying to conform - to follow the appearance and dress code of that birth certificate - feels like living a lie.

Some transexuals are lucky - they put on the clothes and make-up, and no-one is any the wiser.  Sadly not everyone can look so much the role - any they will be the ones who when they walk down the road, people stare, and point, and snigger.

My friend Violet suffered from anxiety - which is not uncommon with transexuals.  The very act of leaving her flat was a terrifying ordeal.  How easily would you cope with having to fend with such unpleasant levels of attention?  It's the other side of the laughter, to understand the tragedy which goes from a desire to just be invisible, so you can hide from the jeers, the prejudice and the hatred.

I have one very good friend now who's going through their own journey in Wellington.  But over the years, I've noticed some others on my commute.  Wellington is quite a tolerant city to live in (I'm thankful to say), and yet even those who are lucky to be "well camouflaged" in their new identity have a tendency to be quiet, and will only whisper in public in case "they give the game away" from their deep voice.

This year there was a male student I'd see on my morning train - and one Monday they turned up to the station dressed for the first time to their chosen female gender.  It made me think of Violet, and I found it incredibly moving - it felt in many ways one of the bravest things I'd seen.

Maybe it's something we all ought to experience once a year - to randomly have to wear the clothes of the other sex, and just not be able to tell anyone the why.  I think though I have some excellent readers - and I like to think you all have open minds and big hearts.  Next time you see someone who you think might be a transexual male or female, just think about all this, and remember the incredible bravery it takes.

Today would have been Violet's 41st birthday - and this blog post is my birthday present to her.

Oblique Testing - it's a resource ...

I've been playing around with the idea of trying to create a set of Brian Eno's Oblique Strategies for testing.  The idea has been around for a while, but I got a useful hook to a fun way of making it work recently.

I've created this ebook about them, although the cards themselves are still "in beta" a bit.  But I'm doing a bootcamp on testing next week, and wanted to include this.  You can print out your own cards from the ebook here.

The Turing report - reporting on scientific process...

Last night's talk from Michael Bolton was as interesting as I knew it would be.  One quote in particular caught my imagination, that I had to put onto Twitter ...

This got me thinking a lot about how reports are given into progress in science.  It's well worth watching such a press release on say "discoveries on Pluto", "string theory" or "artificial intelligence".

The language used is very much like that of a stand-up - and is probably what we need to be emulating in our reports ...

• This is our journey to date
• This is what we've learned
• This is where we're going next

Take for instance the Turing test - this is the test of a machine's ability to mimic thinking by being able to fool someone into thinking they are really talking to a human being (not a machine).

We've made huge leaps in this field since Alan Turing first postulated it.  We're not quite there yet, although we've been "getting there" for about the last 20-30 years.  We probably have a couple of decades to go yet, and even once there, it's a goal that once achieved, artificial intelligence will look for the next goal.

The Turing test caught my attention this morning after reading that Microsoft's recent AI Tay - which was designed to mimic the behaviour of a teen girl, and interact online - has evolved it's behaviour after interacting online.  It now is exhibiting the behaviour of a sex-crazed, foul mouthed, Hitler apologist - so Microsoft had to turn it off (reading this I wondered - did 1st April come early this year?).  I guess you could say her father Bill Gates grounded her after reading what she was saying on social media.

[Perhaps this is also a lesson on the corrupting influence of social media]

In a fit of whimsy, I thought "what if we tried to apply the same rules to scientific reporting as we do to testing?".  With a never-ending focus on "the numbers".

Ladies and gentlemen, I give you "The Turing report" ...

BTW - I like to call this "The Bach Test", after something I learned from James Bach on RST.  If you are trying to get a message across, and someone just isn't listening, and being obstructive, you need to consider walking away (not necessarily telling them to "fuck off" though).  Because when you overly compromise towards someone who is not listening and only has a rudimentary grasp of what you're doing

• you can never satisfy them because their evaluation of what you're doing is entirely arbitary
• to make things even more challenging, you're also hamstringing your own efforts.  It's like someone putting a ball and chain on your leg, saying it'll strengthen you up so you can run even faster.  But they never take it off.

Software testing - when we're preaching to the choir ...

I have very mixed feelings about a local testing event coming up tomorrow.  I should really be excited, it's yet another opportunity to listen to a world renowned software tester - this time, Michael Bolton, whose work and humour I really enjoy.

So why so down in the dumps?  Because of the topic ... test reporting and metrics.  Because I realise "we have to have this conversation AGAIN".

I've posted about test metrics recently here.  And here and here and here and here.  In the 6 years I've been on Twitter, it's been a constant topic in the testing community.  But it feels like we're not done with it yet.

I'm of course excited that lots of testers in Wellington will get to see Michael speak, and some who will never have thought about it, will have their minds widened a little more.  I've looked at the notes for what Michael's likely to talk about, and excited that he'll talk a little about realistic reporting you can do, based heavily on the work he's done in collaboration with James Bach.  You can find the slides to Michael's talk here, and a talk from James on reporting here.

However I was taken back to a comment from Fiona Charles before she spoke at Let's Test Oz in 2014.  I'd just shared a lift with her, and she was about to give her talk "The Battle For Hearts And Minds".  So of course I "wished her luck" (like she needed it), to which she said "thanks ... but I get the feeling I'm very much preaching to the choir".

That off-the-cuff remark really stuck with me, and to be honest has worried me ever since.  I write this blog, and a couple of books.  I present about testing.  I have been called at work a champion for testing before now.

I do get some feedback from other testers especially saying they love my work, and how I explain things.  But I'm constantly worried I'm not breaking new ground the people who don't automatically love what I say or the message of Context Driven Testers and their allies.  It's easy to get acclaim when you're preaching to the choir, but you're not moving forward.

We do need to break the grip of metrics in our craft, which is getting like saying to the guy operating an MRI scanner "I thought you'd use leeches, my old doctors normally use leeches".  That means testers as a community having meaningful conversations about test reporting.  And that means you!  To quote The Lorax,

For me my action plan is as follows,

• Plan testing around measures of reporting which do not use metrics, but build reporting into the structure of the plan from the off.  I've promised an article on this a month ago, it's not yet in the state I want.  I'm hoping Michael Boltons talk will help me out a bit.  But it has to be said, I'm not always able to win this argument and have the freedom to implement (so don't lose heart).
• Keep having meaningful conversations about reporting with my testing peers and managers.  Most importantly showing them ways they can see progress and problem areas.  Even when we have graphs forced, it's never the graphs which show the issues.  Education is important.
• I invited several people I have worked with / are working with to Michael Boltons talk.  Non-testrers who I felt would benefit from it.
• Engel Consulting is bringing Michael Bolton back to NZ in October to do RST For Managers.  I of course would love to go.  But perhaps more important (I'm aware I'm in the choir), I need to try and talk some of the other (non-testing) managers I work with to go because they need to understand how the Rapid Software Testing approach we've embraced works best.

That of course is great, but more than just me, or Michael Bolton, or James Bach, or Fiona Charles.  It needs all of us talking about the subject in a meaningful way.  Michael, James and Fiona can't be everywhere, and they can't win every battle  Testing is a profession we love, and we all need to champion the things we love, wherever we can.

Be part of change!

Based on what?

My son is currently adjusting to the change of education of moving from school to university.  One of the more interesting changes of how his chosen subject (history) is talked about can really be summed up in the question "based on what?".

Up until now, most of his textbooks have included an unchallenged narrative of events and decisions in history.  It would go something like "King Ichabod marched his armies to the Crane Valley, where he fought an unsuccessful battle with rebels.  He decided to move back to a resupply point in Sleepy Hollow to regroup for a second assault".

At University, much more is expected of him, and of his materials to prove such a set of claims.  For instance,

• How do we know he fought his battle at the Crane Valley?
• How do we know he lost?
• How do we know why he chose to move back to Sleepy Hollow?

These claims are based on what?  Basing them on what's been written in other books isn't a terribly strong to build your case on, you can only be as strong as the case they make.

I didn't get to study history quite as far as my son, but when I studied at advanced level, we were given this puzzle "does history really exist?".  The unnerving fact is that really it doesn't.  We can only make educated guesses at what happened X many years ago based on the evidence we have.

• We can have confidence a battle took place at Crane Valley based on contemporary accounts (of the time).
• If we go digging around and find grave sites and abandoned weapons - all of which match the period, that gives us more confidence (even so you tend to occasionally find some battlefields further away than they were believed to be).
• Who won is an interesting one - we generally only read about wars from the accounts of the final winners.  And it's been known for some people to rewrite lost battles in their favour.
• We can know something of what someone was thinking and feeling from letters they sent, their personal diaries, and speeches they gave (if recorded).  Even so, historic figures are well aware of the power of spin and self-delusion.  A defeated general on the run might well put the blame more on his troops than on himself.

Of course talking to my son, what interests me is this is key to being a good tester - to challenge the narration we're being given, by asking for proof and evidence where you can find it.  Whether for history, critical thinking or testing it's a mindset well worth exploring.

Deprogramming the cargo cult of testing ...

This is a talk I've done a couple of times based on an earlier blog item I've posted about how we embraced exploratory testing when we moved to agile.

The talk looks at how we approached the move, and created a tick list of the different "items of value" they got from our waterfall schema.  When we moved to agile, we tried to provide the same value ... but in different ways, using different artifacts.  Essentially a map about engaging and embracing change.

You can watch the video in full here.

Helping people to help themselves

An interesting experience today at the train station - which I wanted to write up ...

Today coming back from work, my head was spinning from a conversation about equality with Gabrielle on Twitter.  Seems I was almost immediately put to the test!

In the car park, one of the car's had it's hood up, and a woman was messing around under it with an adjustable spanner.  In my youth, I've owned a couple of troublesome cars, so know a few tricks with car engines.  There is also as described in Men Are From Mars, Women Are From Venus, a strange male compulsion to take problems (especially mechanical ones) from women and "do the mechanical saviour" role.

Do I offer help?  There was a lot going on in my head though - mainly ...

• "You're wearing clothes you'd rather not get oil on"
• "It's broad daylight, she's not going to come to any harm here"
• "Besides ... looks like she knows what she's doing better than you"

I walked past, she seemed to be tinkering with her battery, whilst I continued to my car.  But I was conflicted - male or female, I always like to be helpful if I can.  I got in my car, ready to leave, and noticed the lady still seemed to be messing with her battery.

If it was a flat battery, I resolved, she could use my car for a jump start.  But she'd have to do "the mucky stuff".  It was her car, she seemed to know what she was doing - don't offer to fix her problem for her, but DO offer her at least a jump start.

So, I drove up and said I saw she was doing something with her battery - did she need to use my battery?  She looked from her work and laughed, "no - my battery's flat, I bought a new one that's in the boot at the weekend, should have just put it in there.  I'll get there".  Help offered, but as I thought, not needed.

How can you help others?

As both a parent and mentor, I come across other people's problems a lot.  One of the fundamental things is a desire to help people solve their problems.  But this often manifests as a need to "take the problem off them and solve it for them".  The problem is, this doesn't allow them to learn how to fix it themselves.

There's a right and wrong way to do it.  Like me today, you want to be helpful.  But you choose how you offer it carefully.  I didn't offer to fix it for that lady, I offered her access to a resource which might help her (my car battery).

Similarly in mentoring, you give another person the option to decide how much help they need, rather than imposing it on them.  Sometimes they might ask for help, and you decide only to give them a little of what they asked for - not because it's mean, but because you're trying to help them find what they can do.

Ultimately it's not about you saving the day, it's helping them to save their own day (with a little assistance from a friend).  Today was a lesson worth remembering.


Is there a problem here?

Here's food for thought ... I never doubted this woman's ability to sort her car.  [In my books you shouldn't lift the bonnet of a car unless you have some idea what you're doing]

In writing this article, I just Googled "woman fixing car" - as a little experiment today, just try it out, and think about what you see.  Even worse, try "girl fixing car".

I'm going to show a few examples below - a few were just what I asked for (I used one at the top here).  An awful lot showed either a heavily frustrated women not achieving much, a sexualised models going "oh help me" (there was more of this when I Googled "girl fixing car"), or a woman plain out just watching a guy repair her car.

Now Google "man fixing car".  Do you see the same kinds of images?  Now, in fairness, I might expect the odd "hunk" in a tight fitting vest, smeared with oil - to be fair, this is as sexy as it got for guys ...

I could see JUST ONE example of a man too frustrated to fix his car ...

And in the few examples when a guy was watching someone else fix their car, that "someone else" was always another guy, and the "watcher" appeared to be helping the mechanic, rather than looking on helplessly ...

No wonder when it comes to mechanical tasks, many women feel like they're not taken seriously.

For the record, I learned my car maintenance and mechanics equally from both my parents. 

WRITING 106 - A scientific template for writing a blog article...

Yesterday my friend Simon Knight published a really good template article about how to write a blog piece - which you can read here.

Whilst I really liked it, I also had some problems with it - which led to a great Facebook conversation, where we talked about our differences.  Simon accepted some of the points - and pointed out that he was using a copywriting model, so there would be some difference of opinion.

I really encourage you to read his article, then come back to this one.  In a nutshell, like a couple of templates I've seen, he suggests you,

• Start with what you want to conclude with
• Find your unique hook into the problem
• Collect together your claims to support your conclusion
• Organise
• Write the first draft
• Rewrite
• Edit
• Read again

Now again, Simon was talking here about copywriting, the "art of writing to sell your product or services".  For that, the conclusion is never really in doubt - it's pretty much "drink our Kool Aid".

As a critical thinker and a scientist, I approach it ever so slightly differently, and I'd like to talk about that approach so you can benefit from it too.  My main problem with Simon's model is he starts with his conclusion, and then finds evidence which will support that.  The problem is, that's not science - it reeks too much of our flat Earth conspiracy theorist who is so convinced of their model, that they sabotage any evidence you present that the world is round.

This is pretty much why when BP sponsors a scientific study, they find no evidence of global warming.  Just like Marlborough's studies never found a conclusive link between smoking and cancer.

The following is the model I use, not just for blog articles, but for doing detailed test stategies as well.

Pick your topic

Sounds simple - but what is it you want to talk about and why?  Is there an article already on this subject?  So what will you offer that's so different?  Remember if someone's already written what you want to say, why not just promote their article?

For this article for example, I'm referring to Simon's article, and giving the bare bones, but I'm really highlighting something that goes beyond what he's said, which I think people need to be mindful about - sifting evidence to support a predetermined conclusion.

Gather evidence

This is probably the key difference, get your evidence first, then work through it for a conclusion.  Here are some great ways to gather evidence,

• Trawl through your own experience, and write down a few examples.
• Google for some articles, or examples in the public domain.
• Consult with everyone you can about the subject.  People at work.  People on Twitter.  What are their stories?

Review your evidence

Ideally you should have more bits of information here than you can use.  Sift through it.  Are there any interesting patterns?

Does anything surprise you?  Anything you might want to look again at?  Don't be afraid to look for more evidence.  Also don't be afraid to challenge your existing models based on what you're seeing.  Is there a better model which seems to cover this topic?  If so, talk about it, and ways to implement it - even better, try it out, and add your learning to the evidence.

Just get the draft done

Like Simon suggests - just go for broke getting it written.  You now know what you're going to use, and how it'll conclude from your review of your evidence.

Just try and keep going through it.  Try to keep it flowing, and don't keep rereading your current paragraph.  If you do, you'll find you keep getting distracted - more importantly you'll forget what it is you're trying to say.

Rewrite, read, edit

Once you've gone all the way through, try and leave it a day or two, and then revisit.  Makes sure it makes sense as a continuum.  Do you repeat yourself?  Is it consistent?  Do you repeat yourself?  [Checking if you're paying attention - I'm allowed to do that]  I talked a bit about this here.

Likewise do you use too many examples?  Are the examples not varied enough?



That's my approach anyway - what I like to call a scientific approach to writing an article.  However in conversation with Simon, he pointed out that you can start out with a possible conclusion - but keep an open mind.  I will give the last word here to him ...

WRITING 105 - Are you your own Mary Sue?

Have you ever heard of the term "Mary Sue" in writing?  It's a fascinating concept that Wikipedia describes as "a seemingly perfect fictional character, a young or low-rank person who saves the day through unrealistic abilities".

It was a phenomenon noticed in fan fiction - where an author creates a character who joins the starship Enterprise or the Millennium Falcon, who typically is a kind of embodiment and wish fulfillment of the author.  Everyone tends to immediately fall in love with the character "who is just so awesome".  They can beat either Spock or Chewbacca at chess, they're more wise than Obi Wan, and can out wrestle Captain Kirk.

It's an easy mistake to make in writing - to think "someone being really awesome" makes an interesting character.  It doesn't.  I previously reread some of my old High School stories, and I'm afraid I wrote centrally about a Mary Sue type character who was just devoid of personality.  But that's a sign of just how far I've come.

A "Mary Sue" can be both male and female.  Obvious examples are Wesley from Star Trek The Next Generation (early episodes were typically "Wesley saves the day ... again), and Bella (everyone loves Bella) from Twilight.  I'm going to go out on a limb here, but I feel similar is true about Jack Ryan from Tom Clancy novels.  I used to notice a pattern, anyone who met Jack just took an instant liking to him - except the bad guys.  They liked him to much he became director of the CIA and later the President of the United States - gosh people must have really loved him.

Developing interesting, complex characters

If we know "Mary Sue" = "dull character", then we can use this to really put down a bit of a formula for what can make a good character.  A high achiever isn't really loved - how many times do you hear a character described as "top of their year with honours"?  (I've actually worked with someone who would describe themselves as such about their school academia, even though it was 20 years ago and they went to a pretty small school in the middle of the sticks.  As you'd expect, they had all the personality of a Mary Sue).

People warm to a story with someone they can relate to.  But they have to have a weakness or a vice, that makes them easier to relate to.  But even that can become cliched - did you hear about the brilliant detective with the alcohol problem and two failed marriages, who just keeps taking his work home?  [Pretty much describes most cop shows]

The formula seems to go "make them really smart in one way, but pretty dumb or inhibited in another".  The classic is Robbie Coltrane's Cracker - a brilliant criminal psychologist, who is an alcoholic, chain-smoking, gambling addict who annoys everyone (they really went all out there - and he's very memorable despite being not likable in a lot of ways).

How about the brilliant, but socially awkward scientist - James Stewart's character in No Highway In The Sky was a real hero model for my father (himself a metallurgist).  In the film the awkward widowed character, with a strained relationship with his daughter is convinced that tail end of a type of aircraft will fall off after so many hours of service, and tries to have the fleet grounded.  Ironically my father, like the main character, would end up working at Farnborough on aircraft safety!

Are you blogging as a Mary Sue?

On the way home today, I was thinking of some blogs I've read, especially in light of a few conversations I'd had with fellow testers...

Think back to yesterday's video from Tim Harford about the Koln Concert of  pianist Keith Jarrett.  Keith had turned up for a concert in Koln, and instead of the piano he'd expected, there'd been a mix up.  The piano was badly worn, out of tune, had sticky keys and particularly in the high octaves it sounded tinny.  He tried a bit on it, but decided he could not work with it, and decided he would refuse to do the concert.

Concert organiser Vera Brandes got a piano tuner in to do the best they could with the piano she had, whilst unsuccessfully searching for something more suitable.  The story goes she stood out in the rain, talking to pianist Keith as he sat in the car.  In the end, he relented, and agreed to do the concert "only because it's you".

You can hear the concert here - and it's pretty darn good (sorry, I don't really do Jazz piano folks, but even to my untrained ear, it's good stuff).  The audience loved it, and the album became one of Keith Jarrett's biggest sellers.  What is so extraordinary is he didn't just play his regular set.  He worked out a way of playing the piano, really banging the keys heavily (it was smaller and hence much more quiet that the one he was after), and avoiding the badly worn and tinny upper octaves.  It was less than ideal, but along the way he created something extraordinary.

I think the trap for us, we should be the Vera Brandes of our team as much as possible.  But we can have a tendency to behave a bit like Keith initially done.  Quite often testing feels "an unloved hurdle, an obstacle which gets in the way", and we're often trying to work under less than ideal conditions, with tools which aren't always up to the job.  It's very tempting to say "I'll be in my car, because I'm not playing".

Granted we need to be frank, we need to have some lines on which we won't compromise, and we need to make it clear when we're working in less than ideal conditions.  But as with the Koln Concert every once in a while is a chance to throw away the rulebook, and do something extraordinary.

So are you a Vera or a Keith?

Who did you identify more with above - Vera or Keith?

I think the Mary Sue trap for us blogging about IT, is we can fall into a pattern of only seeing things from either Vera or Keith's point of view, and blogging as such.

Can you imagine Vera's blog, "oh my God!  Pianists are such prima donnas.  I've spend so much time and effort on ticket sales and promotion.  One little mix up with the piano, and the precious artist refuses to play!"

Or Keith's, "they give me the wrong piano, not even in tune, and expect me to play.  I'll be a laughing stock".

When we blog about our problems in IT, we are acting like a Mary Sue when we are only seeing "our problems".  Not the stress and strain others are under.  Hopefully as I've said you sympathise with both Vera and Keith reading that story.

Whenever I blog about problems in software, I always try and understand and put my mind into "the other person".  See what's driving them, and what they understand.  I can fall into the trap of doing a Mary Sue blog once in a while.  And maybe sometimes that's a good thing - some people reacted well to my topic "those darn estimates" where I'm a bit of a Mary Sue "why do project managers pester us about estimates!".

But I was never happy with that article, and it led me to lots of conversations with various managers about estimates.  That's why I revisited it in "returning to test estimation" with more of a sense of what they felt was important.  I've recently refined my model even more, and hoping to write more about it later when I have more information and a better model that I've tried out a bit more.

What the blogspace doesn't need is another Mary Sue on their soapbox of "everyone should listen to me" and "I told you so".  Trying to understand where developers, business analysts or managers are coming from when they're having friction with testing will always allow you to go to a deeper understanding of the problem area, and lead to better possible solutions.

And that pushes our understanding of testing and how to apply it ever forward.  So get writing folks!

TED talks worth watching

Generally this blog is about original material.  However, once in a while I will find something so extraordinary that I just want to link to it, and "keep it" on the blog - so I and other readers can come back to it.

I don't do it often, but when I do it's because it either so moved me, or I have an absolute need to say "+1" to it.  Here I look at some recent TED talks which have completely blown me away for one reason or another ...

How the worst moments in our lives make us who we are

Here Andrew Solomon talks about people who have had to deal with adversity.  In particular how those who transcend show an ability to forge meaning in their trials ...

https://www.ted.com/talks/andrew_solomon_how_the_worst_moments_in_our_lives_make_us_who_we_are#t-1195138

[If you only have time for one talk, this is the one I'd recommend]

How frustration can make us more creative

A recommendation from my parents no less!  How well they know their son.

Contrary to what me might seem common wisdom - it's often when we're just a little uncomfortable.  When thinks are a little disorganised and maybe even chaotic.  These are the time we're actually much more switched on and creative ...

https://www.ted.com/talks/tim_harford_how_messy_problems_can_inspire_creativity

Really "mixing it up a bit" and Brian Eno's Oblique Strategies sound useful for many an agile team.

Trial, error and the God complex

Economist Tim Harford looks at complexity in the world, and the "God complex" trap - where we think we understand things, and try and simplify our approach.  He argues that we evolve our approach best by adding a bit of randomness and taking a trial and error approach.

This really resonated with me.  Recently I took part in James Bach's  challenge on integration testing.  He set a problem, and I gave how I'd approach testing it.  When he asked me why I'd do some of it - what problems I'd expect to find, I was tempted to change my scope, and do less.  But he reminded me you don't always have to justify everything - if a test is simple, and is there out of curiosity, don't feel the need to justify every test you do.

Likewise in agile, we'll test functionality around a story, because we know that's where the most change has been.  But sometimes we want to test manually in areas we know haven't changed.  The God complex tells us that area hasn't been changed (that we know of), so it's a waste of time testing.  However, once in a while, we find something has got through - and our God isn't as infallible as they led us to believe.  Trial and error will find things that God complex cannot anticipate, and it's an important tool for us a testers!

https://www.ted.com/talks/tim_harford

[This talk echoes some themes I'm encountering reading Thinking Fast And Slow]

WRITING 104 - Lessons from Jasper Fforde

This week just happens to be "Writers Week" in Wellington and I managed to get to a talk by Jasper Fforde on his experiences as a writer.

I seriously love Jasper's work - like Terry Pratchett, he creates books that are surreal flights of fancy, but with their own internal logic.  My favourite are probably the Reading Nursery Crimes - a procedural crime thriller with a nursery rhyme twist.  Or indeed the alternate world of "Thursday Next", where England was invaded by Germany, President George Formby led a rebellion, Wales became a socialist republic, and everyone is fanatical about plays and books - to the point where there are shades of literary hooliganism, with occasional violent clashes between fans of respective authors.

As this fits in nicely with the current theme of writing, I thought I'd provide a quick summary of what he had to say.  Firstly, as he pointed out, story is something that's incredibly powerful to us as human beings.  We love to share stories - whether it's around the campfire as early cavemen or around the office watercooler.  Indeed, most of our learning is wired into storytelling - which links into my tale last time of examplification - we can often remember a tale far longer than the "moral of the tale" alone.

Think about why the stories of Shakespeare, which remaind enduring in one way or another, even though the language is dated - because people are still falling in love with people they shouldn't (Romeo and Juliet), driven by insane jealousy (Othello), being led astray by flattery over truth (King Lear) or just generally going into forbidden jealousy and becoming the playthings of supernatural spirits (Midsummer Night's Dream).

Even if I was to say to you "be a good Samaritan", it only has meaning because of the story in the Bible.  And the story was one Jesus used himself to illustrate the concept of being a neighbour to another - in the biblical context the Samaritan was a different creed to the man who was robbed on the road.

[As a side note - I also thing that defects always work more powerfully as well if we talk about them as a story of sorts]

Much like any workshop with any writer, an all-too-common question came up about "how do you become a writer"?.  Jasper was interesting on this - his writing has a good understanding of literature, and I've always assumed he'd studied English at University.  Wrong - he had been a school dropout.

After school he'd worked as a focus puller on movies, and had become interested in maybe writing a film one day.  So he started to try and write - and initially he was terrible.  He'd mainly write short stories - but he found that he really enjoyed doing it.

Many people want to know if there's an easy way to be a writer - but there's no short cut.  Just like there's no short cut to becoming a marathon runner.  But you can become one in the same way.

Can you run a marathon now?  I'd assume the answer is no.  Could you be able to?  Assuming you have two good legs and decent enough health - quite probably.  But you'd have to practice - run a few times a week, just whatever you were comfortable.  If you wanted to get really good, you might want to see how other people run, and try mimicking them.  You might even want to film yourself running and see if there's anything you need to modify.

Jasper's advice was similar - write, and enjoy writing.  Read back some of your old stuff - be prepared to be critical, and always ask "how could I make this better?".  Read other people's fiction, maybe even play around with mimicking some of their writing, and find out if it feels comfortable to you.  Every time you apply this, you'll get a little better and better.  You'll make the odd typo and do their/their/they're wrong occasionally, but don't beat yourself up too much.  Revisit your material several times before passing it on.

For myself, I preferably leave an article a few days or a week before rereading.  At bare minimum have a coffee and a context break before rereading.  For a standard blog piece, I reread an article about 3 times before it gets published (it's about 5-10 reads for anything in a book).  I particularly have noticed if I work on something over several days, everytime I "take a break" I pick up in a slightly different style.  Sometimes I'll have said the same things several times, without noticing.  It can all be smoothed.

Sometimes I'll royally get stuck, and will email a friend what I have so far and ask for ideas advancing it - sometimes I'll use Twitter.

In a style similar to testing - I'll reread a couple of times until I can't find any other mistake to smooth.  Even so I'll sometimes reread months later and see a their/there/they're calamity!

But as Jasper reminded us all - most of all have fun!

It should be International Celebration Day ... EVERYDAY

So this week was International Women's Day - look it up here, it's a thing.  And yes, there's an International Men's Day too if you're worried.  Although to me, International Talk Like A Pirate Day sounds much more fun (I need to remember next year).

What I thought was quite nice, there were some folk on Twitter thanking and celebrating women they'd felt had been influential.  The problem is - if you missed it, then I guess you need to wait 365 days til next year to celebrate someone you thought was influential.  Heck, less if that person is male!

Or maybe you can tell them right now?  Or let the world know right now?  What's stopping you?  Do you REALLY need a special day to do it?

Celebrating people in our life is something I think we can be really crap about.  It's "not cool", and certainly something as a teen-uncomfortable-with-emotion brought me out in a sweat.  It's unfortunate, but it took something sad to snap me out of it.

I've talked before about my grandmother who died in 2014.  She was very dear to me, but I couldn't always say it.  Sadly she was diagnosed with early Alzheimer's the week before I got married - it was an absolute bombshell for me - I realised she wouldn't be around forever.  But as sad as that realisation was, it led to something good.  It made me realised that saying "I love you", holding her hand, hugging her as long as I could - it was all important, and it made her day.  And as hard as losing her in 2014 was, there are no major regrets - and those memories you have are all the "warm fuzzy kind".  You only regret there wasn't room for an extra one or two.

I guess I must have got into the habit - when my friend Violet died unexpectedly in 2010, I was obviously sad, and continue to be.  But I know I told her how important she was, and said all those important things that need to be said between best friends.

Make celebrating people and being thankful for them something you don't wait to be prompted for "a special day" to do.

WRITING 103 - Examplification ...

In the last couple of weeks I've reviewed two articles for people - ironically both called Simon.  [One is Simon my brother, one is Simon who I talked about previously]

Now, they'd both written very good pieces.  But from applying a simple suggestion from me, they managed to raise the bar.  They'd written some very good theory, but in order to convey something about that theory, they really needed an example.

Examples are a great way of getting a point across, and one of my simple things to consider when writing.  I'm reading some critical thinking books at the moment, and I heavily rely of the examples as a great way of showing the nuts and bolts of a concept.

Indeed, Lisa Crispin told me during writing More Agile Testing that the "sidebars" of people's experience reports during her first Agile Testing book had been one of the most successful point of her and Janet Gregory's book.  I had to agree - agile was such a radical concept when I first read it, and the experience report examples really helped me to get to grips with some of the ideas!

Often within this blog, I'll talk about an idea, and use a kind of cultural shorthand - picking out an example from a popular film.  This makes things easier for me, because I try and take something you're already familiar with, and analyse it - it makes the storytelling easier for me.

Now that'a good for semi-familiar concepts - I for instanced used Star Wars to talk about team building in this post.  However there's also a danger of alienating the reader - as Dan Billing warned me in a private discussion.  If the reader isn't familiar with the media piece you're using, then they'll go "huh?" and you lose everything.

Of course the best kind of example is when you take it from your own life, and apply suitable "anonymity" to the tale that you don't risk damaging relationships with someone or needlessly calling someone out/damaging their reputation.  I generally anonymise stories - with the exception of the odd Rex Black antic or indeed when I finally said "enough's enough" about Bob Marshall's behaviour.

Generally for each point just a single example will do.  If the point is a main theme, you might want up to about three examples, each offering something a little different.  Avoid different examples which don't offer anything new from each other.

Here's an exercise for you.  You've just written the words "we all know it's important to test early" - now back it up,

• Come up with an example of testing late, and how it stung?
• Have you ever found a problem in software early on?  Did you feel you stopped a major overspend?

Enjoy - and get practicing!

WRITING 102 - the "R" word ...

In Back To The Future - Marty McFly goes back in time, and meets his father as a teenager.  He's somewhat shocked to find George McFly writes stories.  At the time George's words really struck a chord with me ...

George refused to let anyone else see his writing because, as he puts it, “What if they don’t like it? What if they think I’m no good? I just can’t take that kind of rejection!”

In this article I'm going to tell you about some of my rejection tales - partly so I exorcise some personal demons, but also to really take the sting and fear out of it for you.

Eeek - it got personal!

I never really saw myself as a writer, but back in 2006, I met up with a group of friends who like me were Doctor Who geeks, and enjoyed making Doctor Who themed audios.  I starred in one of those dramas, which you can find here.

The problem came though when I was approached to write a story myself.  I wrote several.  And numerous rewrites ... which were then "dropped".  Sad to say, I did take it very personally (not helped by the fact that they decided not to tell me that decision, until I flat-out asked "when are we recording one of mine?"), and it did cause a lot of friction between us all.

But here's the good news.  I never saw myself as a writer until then ... but then I had a feeling of "something to prove".  Which pretty much "lit a rocket up my arse" to get writing within testing, and led to the first publication on this blog in 2010.

Don't be afraid!

So I started blogging here in 2010 - and I tried to blog regularly.  Initially my blog reader count, and the Twitter account I used to promote was pitiful.  I was learning as I went.

But with each post, I got better.  As I found when I used to run a comedy blog in the early 2000s (the material for which is too dire to reproduce), the more I wrote, the easier it got.

Soon enough I got a desire to get published in The Ministry Of Testing's Testing Planet.  I even ended up getting a position on the editorial staff.  Simples, yes?

Actually, no.  I actually got my first three submissions rejected,  On the plus side, you could say there wasn't a culture of favouritism to the staff going on.  It was a little frustrating for me, especially because as a reviewer I did everything I could to work with a writer to get their article to a publishable state.  And I did feel a little like I wasn't being extended the same courtesy.

However, there were multiple reasons,

• My first article, "The Agile Haka", had already been published on this blog, and there was an "exclusive content" clause.  [Be aware of this for some places]
• My second article "The View From The Test Manager's Gallery" was written exclusively for publication on test management, but rejected by Rob Lambert for being too long for the paper.  I was kind of gutted, but Testing Circus got behind me to publish it.
• My third article  "Schrodinger's Code" was alas too derivative of an article by Elisabeth Hendrickson.  I sometimes feel guilty I don't credit Elisabeth more.  I think although I don't try and emulate her, her writing style has been extremely influential on me - more than any other software testing writer.  Because she taught me to embrace storytelling, and it is okay to be off the wall.  I'm really saddened as you can imagine that she doesn't have as much time to write these days.

Thankfully Testing Planet owner Rosie Sherry knew that at three rejections, it was probably my limit before I just gave up and stopped submitting.  So she handed me to the very capable hands of new editor Simon Knight, who worked with me through my Schrodinger's Code article to produce something on a similar theme, but exploring it in a different way to Elisabeth.

He asked questions, asked for elaboration, asked for clarity .... it was a fun experience, of writing, and being challenged to push myself further.  The end result was an article called "The Software Minefield".  To be fair, the article was better than what I was capable at the time, and it led to a good friendship between myself and Simon.  I eventually was even given an article by Simon to review - submitted under a pseudonym so I wouldn't show favour!

If the price of three rejections was the price of getting to know Simon, it was well worth the price of admission.  I learnt a lot about pushing myself as a writer from him.  I also learned a lot about editing from him.  In fact I'd not have been as good supporting More Agile Testing as a reviewer if not for Simon.

It also led me to the ultimate accolade, where my brother (another Simon) asked me for his help writing an article on change management.  Sibling rivalry is a force to be reckoned with - just ask Cain and Able!

Ultimately, what I'm saying is, don't fear rejection.  Dare to write - but don't be afraid to ask someone "I'm new to writing, this if what I've got, any hints?".  With luck you'll find your own Simon Knight to help you become the better writer!

The Software Minefield

This article was originally published in The Testing Planet magazine, as was the titular piece of my first book, The Software Minefield.

Let me take you on a journey...

You are with a party of friends on a beautiful walk in the countryside.  It's a lovely day, and according to your map you are making good time.  Some time soon you should arrive at your destination - a café which has come highly recommended to you.  You can almost smell the coffee and cakes now!

As you open a gate a sheep accidentally comes through, and soon bounds off in front of you.  Imagine the total shock when with a sudden BOOM it explodes before your eyes.  It's at that moment you realize that although you didn't intend to, you've somehow entered a minefield.

 Suddenly your beautiful day has become treacherous and your good progress has lead only into peril.  The only way you'll get out alive is by making good decisions from here on in.

 There is no doubt that software development echoes this parable in many ways, especially when it comes to testing.  Our projects can often seem to make good progress, but little do we realize we're just getting ourselves deeper into a minefield.

As testers we can often feel much like that rambler, we know there's peril out there in the form of defects, but we're not sure where exactly and of what severity.  But often to the rest of our party the wake up call will only come when the first mine has gone off ...

How do we best deal with minefields?  And how can we apply that to software?

One approach would be just to back up and hammer a sign (okay, being very careful where we hammered it) to warn "Caution Minefield". Then we can quite happily state that anyone entering does so at their own risk, and we did warn them.  Some companies have indeed taken this attitude with customers, saying "well our customers will let us know if they find any problems".  The problem with letting customers loose in a minefield is that you could soon find yourself running short of customers...

In a similar vein, we can follow the example of history, and drive a flock of sheep over the field, and find problems that way (helps to have a bottle of mint sauce handy though).  This can be what happens when we let loose 'end users' on our system in a controlled way, and "if it doesn't fall over it must be okay ... but no people will be harmed".  This is rather quick and dirty way to test, and although it should find a lot of problems, it's rather random, and not guaranteed to make it completely safe.  Who knows what bits the sheep might be avoiding ... indeed the sheep may have a mentality towards self-preservation the shepherd isn't aware of.  Maybe the grass above a land mine just isn't juicy and fresh enough to tempt a sheep.

Much better is to bring specialist mine hunters or engineers in to clear a path.  They will need some expensive equipment like metal detectors to probe ahead, and when a mine is found, they need to work with an expert to remove and defuse it.  But this is slow and methodical work, with everything almost grinding to a halt when a big problem is unearthed.  In the story above, as your engineers clear a path, there will be someone who will complain it's too slow and the café will be closed by the time you're across the field.

And though you'll have cleared a path, it may still not be safe.  Your friend needs to go to the toilet behind a bush whilst this is going on, but that involves stepping off the safe path.  When can you declare a field safe and move on?  Do you keep going backwards and forward with your engineers until you've covered every square inch?  Do you cover the main footpaths first?  Or can you claim it safe if you've not found any mines for the last couple of hours?

How can you ever really be sure?  It's easy to know about the presence of mines - they have a way of making their presence known - but how can you be confident of their absence?  How can you be sure that as you're unearthing mines in one part of the field, some scoundrel isn't laying new ones in the other end (ooh, and you thought the minefield was static - that could be a dangerous assumption)?

That question is of course one that applies to testers, managers, developers.  How can you be sure you've de-mined your software of defects?  Of course you never can be sure, but it doesn't hurt to have covered as much ground as possible.  Every mine you find makes the field safer.

In reality we tend to bring in our specialist demolition engineers, our Testers to check methodically as many paths as possible.  Then to cover ourselves, we bring in our users for acceptance, and send out the sheep ...

 As with so much in life there's no "one way" to solve this problem scenario.

There's really no way to one way, no right way to solve this.  You have a drive to get somewhere (your café).  But you can easily spend the rest of your life going backwards and forwards in this field before you can declare it safe.  Of course if you're careless, you will be spending the rest of your life here.

At the end of the day, the most important thing is we and everyone in our party respects that we're in a minefield, and act accordingly.  Not letting our leaders persuade us "you're all being silly, it's just one mine, c'mon follow me, they'll be out of meringues if we dawdle ...".

WRITING 101: Why I love to write about testing ...

I have obviously written a lot about testing - I've over 200 articles here, a couple of books, and such an assortment of postings in various testing publications that I don't remember them all.

All of which might sound like a brag, but it isn't.  Writing might seem to come easy to me, but it doesn't ... on my blog there are a lot of articles which are "in progress", but aren't ready.  Sadly one of those is the upcoming article on test reporting, which I've spent several weeks on, but still aren't happy about the direction.

But this is an excellent time for me to talk a little about the writing process, and maybe encourage you to take it up a bit yourself.

In the heart wrenching movie Shadowlands, there is a line (amongst many very thought provoking moments from that movie) that I've always resonated with, "we read to know that we're not alone".

I have my own quote for writing, "we write to make sense of the world".  To me, it's the heart of why I write - because I've got something to say.  Often when I start, I'm not exactly sure what it is I've got to say, and it takes exploration to really discover what it is I want to say.  And sometimes that surprises me.

Right now, on test reporting, I know that test reporting really links back to your "test exit criteria".  They are a measure of "done" against your test exit criteria.  It logically means that your test reporting can only be as good as your exit criteria.  So guess what happens when you have shallow and lazy exit criteria?

Damn - that's thrown me, and rather than a simple article about test reporting, I now need to have a deeper think about what makes good exit criteria.  But it doesn't disillusion me - not at all.  It means I have to think deeper, and search harder through my personal experience.

But it also means that when I come on "the other side" of that article, I'll end up with a deeper understanding of the topics and the pitfalls.  An understanding I hope I can take to my next project - onwards and upwards!