Saturday, February 28, 2015

Farewell Leonard Nimoy

Growing up can be a grim affair - especially in early 80s England.  The news seemed ever present with tales of flare ups between America and Soviet Russia in the cold war.  And we were obsessed with the question of whether possessing nuclear weapons ourselves as such a small country deterred invasion, or just put us on the frontline of nuclear invasion.

It was something that just seemed to be reinforced in so many lessons at school.  In physics talking about fusion and fission, we were reminded how one modern nuclear weapon would take out most of the country.  In history we studied not only the decision and effect of the bomb at Hiroshima, but the after effect, with the knowledge of how many orders of magnitude more powerful modern weapons had got.  And in English, we were made to watch Threads (a story about nuclear war, and how society would unravel) alongside reading the book Z For Zachariah, a tale about post-nuclear holocaust survival.

Somehow the popular lyric from the Morrissey song "Ask" summed up the mood of many, "if it's not love, then it's the bomb ... that will bring us together".

And then there was Star Trek.  Creator Gene Roddenberry often attributed it's success to it's "optimistic vision of the future".  It was the 23rd Century, and somehow mankind had avoided annihilation and reached for the stars.  It's little wonder then that I found myself wanting to lose myself in this world.

And then there was this guy ...

Life as a young teenager is one of confusion - in my scenario above, a little more so.  To say the I identified with the character of Spock, somehow doesn't do it enough justice.

He was smart, strong (as a boy going through a growth spurt you seem suddenly to get super-strength compared to the puny thing you used to be), seemed to have a haircut given to him this the aid of his mother and a bowl and as the only alien on a ship of humans, always a bit of the outsider.

He was a character who displayed a calm and rational demeanor, finding any show of emotion somewhat vulgar (typical teen boy then).  But beneath it all he had the same emotions as all of us bubbling up, and sometimes in episodes such as The Naked Now, they came to the surface.

He tried to appear that he didn't need friends around him, and yet he had them anyway.

He was then to myself and to many others, a character we found a deep connection with - someone who somehow went through many of the same trials as we on a daily basis.  He even occasionally got into a fight with one of his friends over a woman he fancied (despite claiming to be a pacifist vegetarian) ...

It's quite natural and normal when you have so much affection for a character for that affection to spill out to the person who played them.  Even knowing, that actor and character are not the same person (this is good to know if you ever meet Jack Gleeson at a convention).

For actor Leonard Nimoy, this was a difficult thing - all told his appearance as Spock counted for 3 years of work during the 60s, and 8 films he's since appear in.  To have played a role which brought such instant recognition was both a blessing and a curse.  His first autobiography "I am not Spock" had him trying to distance himself a little from the role, like any person going "look, I can play other roles you know".  With his second book, "I am Spock", he'd found himself embracing how rare it is for actors to have played a part which so touches and grips so many.

I've followed him on Twitter the last couple of years.  He wasn't Spock.  But all the important things we find so important in his character were reflected in him.  A desire for rationality over rash reaction.  A wry wit.  A passion for peace.  And always his posts signed off with LLAP - Live Long And Proper.

The alien character of Spock will always be with us, but there will be a vacuum left by the man who was Leonard Nimoy.

Friday, February 6, 2015

The direct route ... or the interesting one? Managing time and goals, whilst allowing for discovery

Over the summer holidays, I've become increasingly fascinated with how we as individuals plan and spend time.  Putting my families behaviour under the microscope, I've found once I returned to work that we perform similar planning in the office.

It's interesting, because we tend to just go along with a certain path of behaviour, which like many habits we tend not to be conscious of.  When in January we visited Auckland with my parents it allowed me to take notice of how we spend time and make decisions as a family group.

"The itinerists"

Let's start with a pattern of behaviour my family don't do regarding over-planning.

As a resident in New Zealand, when we take holidays within the country we always find it somewhat easy to tell the tourists.  For me, I tend to call them the "itinerarists".  To be fair, they're visiting the country, and trying to fit the whole experience into 2-3 weeks, which means they're operating under a tight schedule.

So everything is done to an itinerary.  They only have about 48 hours in each location before moving on, so there's no room to hang around.

These people used to stand out like a saw thumb - they typically had a clipboard (it's all iPads now though).  At the Waiotapu geothermal park, they were the ones who as soon as the Lady Knox geyser erupted would be dragging the rest of the family around, going "we're on a schedule ... can't watch this all day".  Tick that box, move on ...

To me, "being on a schedule" always meant that you get to see a lot of things, but you don't really take time to enjoy what you're seeing either.  That's not how we tend to do things.

Aliens Landing!!!

The best way to describe how my family operates is to tell a story of one of our journeys.  This event occured when I was a kid in the 80s, before the days of smartphones or even a tape player was available in the car to keen us entertained.  [Oh the horror - we used to sing folk songs on the way to holiday ...]

We used to travel from where we lived, to my grandparents in Stoke-on-Trent fairly regularly.  It was over an hours drive each way, and often we'd be driving home in the dark.

It was during one such nighttime journey that my mother acted a little panicked.  "We need to go back ... I saw something ... it looked like an alien landing".

If we wanted to get back at a decent hour, we really needed to keep going.  But what the heck ... our family included my father (who was a scientist), my brother and I (who'd both go on to do science at University) and my mum (who pretty much tutored us to be rational-thinkers and engineers).  That makes for a whole car-load of curiosity ... so there was no way we were just going on ahead

It wasn't simply a matter of turning back.  We could see something oddly lit, but way off to the side of us.  That meant trying side road, which sometimes which didn't take us very much nearer.  There was a sense of exhilaration, and even "is this particularly wise?".  But we had to know ... we needed to know ...

What we found was odd indeed, and yes, in the night light it was a strange and alien sight.  But it wasn't of alien origin.  Turns out there was a large JCB plant there which we'd never seen, and someone had built a giant sculpture from JCB parts.

We were impressed - in fact, this became a new route home from my grandparents that we'd often use from then on.

The story really outlines how we function as a family (even now when my folks were over in Auckland with us), and indeed how I love to function within my test team.

We have a broad goal

We're driving home.  Our goal destination is our home.  We had some time constraints on us (we had school the next day).  If for instance we were rushing home for a TV program on that night, we might have listened to my mum's tale and gone "interesting ... but nah".

We're not tied up by the itinerary and goal of getting home, that it's not possible to do some exploration.  But had it gone on for more than half an hour, we'd have probably abandoned it as a wild goose chase.


My mum came right out with "it looks like aliens".  In hindsight today, I don't know if she knew about the place beforehand and manufactured the adventure.  My parents are the kind who'd love to do that to make our lives more interesting, and keep instilled within us our sense of wonder.

My brother and I were always going to be more engaged to a tale of "I thought I saw an alien landing" over "hey kids, I hear there's this really neat sculpture".

However at the time it seemed real.  We trusted to what mum had seen, and even afterwards when we discovered the truth, we didn't mock her going "are you seeing aliens again?".  We understood why something like that would look alien.  Alien was a very apt description of it.

Sometimes you need people around you who you can describe exactly what you think you've seen.  Even if you know it doesn't particularly makes sense at the time.

Decision making as a group

We made the decision to go back as a group.  We all wanted to know more, but we also didn't want to spend all night doing it.

When we were in Auckland back in January, each day we'd have a rough plan of what we'd want to do.  During the day we'd sometimes find new things we'd want to do which we hadn't known about before.  Did we stick to our plan, or reach a compromise.  We're loose enough with our itinerary that we can swap events over, do new things, or drop some items.  Sometimes one of us got a bit unhappy about that, but then we work to make sure not everything someone wants is being dropped (it's really hard to keep a herd of 5, quite strong-willed individuals happy all the time).

Coming back to the office in 2015 with this experience fresh in my mind, I realise that there are a lot of parallels of this into how I like to operate with my test team.

There are a lot of people who think being a test manager just means creating an itinerary for test scripts.  On Monday we'll do TC01-12, on Tuesday we'll do TC13-24 ...

In fact I've been on projects where that kind of planning has been absolutely demanded.  It's somewhat foolish, as invariably testing uncovers defects, and that means automatically that you're not going to complete what you plan, and before you know it, you end up re-planning every night.  Usually on the basis that "everything will work fine tomorrow".

It gets really tiring, and doesn't really add any value - testing at it's heart is dealing with some factors which are uncertain.  We know for instance we'll encounter some bugs, but we lack the foresight to know exactly where and how those bugs will manifest (I have tried crystal balls and tarot cards, and it's impossible to get that information ahead of time - best I have is guesses based on previous similar project experience).

Another problem I find with this re-planning approach (as with any over-planned itinerary) is that pretty soon, it can be that this tick-list of items to show progress becomes the goal.

With the itinerist on their holiday, soon that daily plan can take over, and we find we dance to the strings of what we've planned.  The funny thing is though when we originally booked the holiday, we probably did so "to see another country, to relax and have fun" ... shame it doesn't say that on our check-list ... no time for fun, we have another event scheduled in 30 minutes.

Most definitions for testing, even those from ISTQB have the aim of testing as not to tick off a list of activities, but to find software bugs.  So, when it comes to planning, I much prefer to split the testing phase into a series of small milestones, or what Johanna Rothman calls inchpebbles.  They are a series of goals to have for your effort.

If you looked at our trip to Auckland, these were our original goals (our inchpebbles),

  • Visit the Auckland War Museum
  • Take a trip up the Sky Tower
  • Take the ferry to Takapuna
  • Check out where the Universities are (my son does University next year, and is considering Auckland)

We ended up expanding the ferry trip to include a harbour tour and a visit to Rangitoto, this was good, but meant we didn't really do as much in Takapuna as planned (but heck, we got to see a lot of the city on that tour).  There were places we planned to go to dinner which we ended up swapping for other places we encountered along the way.

Within a testing framework, you might be testing your new system - you'll find that certain of the tests group together organically and it's possible to umbrella them together.  Looking back that the "back to basics" series of articles, I set a series of inchpebbles for testing for "registration", "login", "account self-management" and "helpdesk support".

I might break this down into a series of timeboxes, giving each a different value according (typically) to the richness of features in each area,

  • registration - 2 days
  • login - 1 day
  • account self-management - 2 days
  • helpdesk support - 3 days
I'll also probably have a pot of time for "general retesting" for any time I'm expecting to lose due to problems in the build, waiting for fixes and retesting defects.

An important part of this model is like any journey it encourages some level of exploration by testers performing the task provided (as with our JCB alien hunt), to detour "if they think they saw something odd", and even try new tests.  If they're working on a one day task, and their additional testing is going to be about 30 minutes, then let's not even discuss this - just do this.

If your testing is going to take half a day or more, then let's discuss this before chasing - what are you intending to do, and much like our car journey, let's make a decision as a group if it's worth the detour.  Let's weigh the risks, and decide between going off track now, or maybe finding time later to run the tests you want to (especially if they're more invasive to the system).

But regardless, when testing, we need to appreciate that sometimes we need to take some of the side roads, and to empower our staff that it's okay to do so.  Our job as testers is to find the unexpected, and sometimes that means the occasional detour ...

Monday, January 5, 2015

Back to work 2015 ...

For many of the companies I've worked with, which operate a compulsory closedown period over Christmas and New Year, today represents the first day back at work.

Returning to work after an extended break is a good indicator regarding how we feel about our work.  Of course any of us would choose holidays over work, but if there was a feeling of genuine dread at returning to work, it's a good sign that something is amiss.

For many, the core of that sensation could have several roots,

  • Feeling underpaid (which often goes hand in hand with feeling under-appreciated).
  • Having one of those co-workers who just pushes your buttons a lot.
  • Feeling you're not in control of your work.
Many will find the solution to this to look for another job, hoping especially that it will be better paid, with nicer people and they'll get more control of what they do.  However that's usually the step of last resort.  If we find we're moving jobs every time that we're a bit unhappy in our job, we'll find ourselves moving a heck of a lot (every few weeks).

But unhappiness is a sign that something needs to change.  With those points above, the common cause for those feelings is a feeling of not being respected.  The good news is though that you can be an agent of change, and also you are not alone.  

A quick scan of Twitter and relative testing blogs and magazines will expose you to many other testers experiences in these areas.  A quick Google of your problem can often lead to a lot of sites with advice - although of course, you always need to apply your critical judgement (you wouldn't be a tester if you apply advice blindly).

Whatever the challenges for you ahead, I hope there is a blog post here that can be of help.

Happy New Year!

Monday, December 8, 2014

Voices From The Past 3: Searching for the Holy Grail

My son was born in 1998.  I found parenthood an initially terrifying experience.  Like many you're bringing a new life into a world, that you have to admit "you don't really understand at times".  Having the next generation in your hands brings that into focus - at some point ideally you'd like to help this new life deal with the world as well, if not better than you do.

Over years I would call this quest for understanding by several names.  One I've come to like is "pathfinding", but back in this initial entry, I found that "the search for the Holy Grail" seemed best ...

The Search For The Holy Grail [1998]

This is a beginning, and as I write these words they pass on into history.  This is the way of things.

This is a book about the quest for a Holy Grail, in this case not the cup of Christ, but the quest for a truth which grips and defines our lives.  It is a record of my thoughts and feeling laid out on paper, not just for myself but for my son and any other children to come.

Our Family Motto  [1998]

Our family motto is this,

Nothing of steel is made without fire
And the trials of life are the flames 
from which we draw strength

Life can be full of hardships and difficulties - all too often they seem overwhelming.

Unfortunately life does not seem to be about finding a calm idyllic life, but instead dealing with one obstacle after another, and it's easy to lose faith and hope.

In facing each obstacle, you can find within yourself new abilities to cope with.  Abilities that you're not even yet aware of.  These challenges make us stronger people.  Hence challenges can make us stronger people.

From the day we're born, life is full of difficult things to learn - if we gave up after the odd failure we'd never walk, talk, or learn to read.  But as adults we forget how hard the learning process can be and get to fear failure.  [Interestingly I wrote something similar 12 year laters]

Never lose hope.  Burn our motto into our hearts when things look hardest.

Looking back  [2001]

I have found this book after having lost it since we moved from Portland.  Rereading it, I found myself thinking "wow - it really resonates with the choices I have made in the last few years.

Recently I have found myself "pathfinding", searching for my unique spiritual and mental path in life against the needs of day-to-day life.

Of course for me, rereading this is a weird feeling, and gosh (did I ever used to say "gosh"?) do I wish I could transfer my knowledge now to the guy who wrote that first page.

But you cannot pass knowledge back in time - only forward, and that is the aim of my writing ...

The Two Forces [2001]

Our life is gripped by two great forces which while balanced give us life and health.  They are known to us as renewal and decay.

The force of decay is constant and unfaltering and come from outside.

The force of renewal is generated from within - from our heart, our mind, our body.  One day it will fail and we will surrender to decay.  But for today, it is enough.

A few years ago I saw a dead mouse on the way to University.  Each day I passed it, it was a little more decayed than the one before.

I realised the that the mouse not not decaying because it was dead.  Every day of it's life it was decaying.  But at the same rate it's body was also renewing what was lost to decay.

When it died there was no more renewal, and only decay remained.

So?  Nothing is static, everything changes.  That's part of the trick of life - things that do seem static are in a state of static equilibrium (where two opposite forces are producing no net effect) or decaying at a very slow rate (mountains erode but over thousands of years).

In relationships particularly we can think that once we are married it becomes a static thing that will last.  No!  To maintain a relationship even after marriage we still need to put in energy, time and love to keep it alive.

Of course we should not be afraid of letting it evolve - as long as we are not letting it just decay ...

My grandmother who died this year kept a journal for years, which my mother is inheriting.  I know for myself, I'm not ready to read them yet, her loss is too recent.  But I hope one day I will.  With Violet, I have found her occasional writing, and it's a bittersweet affair to remember her words and thoughts.

Voices From The Past 2: The wannabe sci-fi writer ... what it taught me ...

On my last article I was talking about how I've discovered a box of my old writing, and how looking through them has been an interesting exploration ...

What I was really excited about though were a set of old exercise books that I found which have various ages on them.  The oldest date back to when I was 13, and are my attempt to write a "story bible" for the universe of space opera stories I tried to write.  Those ones are pretty dreadful - they describe the Space Scout Fedaration, and a starship called Zeko (there are a lot of words beginning with "z", classic bad sci-fi).  The whole thing reads like such a bad fusion of Star Wars and Star Trek, that I had to check the cover to make sure it was my name there, and not JJ Abrams (nope, not a big fan of what he did in Star Trek, so not looking forward to Star Wars VII).

What interests me most is how different the style is now compared to then.  A lot of that change came from my first writing coach who was my mother who gave me feedback to get better.

I would see something in my mind, and I wanted to describe exactly what I saw, so another person would see the same.  But the problem is it was kind of dreary.

For instance, if I was writing Star Trek fiction, it'd be "the starship Enterprise moved into orbit around the planet.  It was a large spaceship some 300m long, with a large saucer front section which housed its many crew which connected to a large engineering cylinder which housed two large cigar-shaped engines on struts just behind the main saucer".  Ouch.

Thanks to my mum, I learned to let go of trying to cram that kind of detail into people's heads.  It's confusing - most people know what the Enterprise looks like, and in actual fact it's typically not that important to reading a story.  However I felt I needed that detail "just in case".  Really you don't - if your ship has been hijacked in engineering and your bridge crew need to battle down there, you can always have someone go "but Captain, the engineering section is 13 floors down, and we don't have control of the turbolifts" (obviously someone has a fear of stairs).  If you really need to, you can have someone explain something (as with that "13 floors down" statement) as a method to explain to the audience.  In Star Trek The Next Generation, everybody seemed to need to explain everything in this manner to Riker - he always seemed a bit slow on the uptake (and he kept wondering why they stopped offering him his own command).

Some of this of course came back during Let;s Test Oz, where we had a workshop on communicating with Joanne Perold and Carsten Feilberg.  The aim of the exercise was as a business owner I had to describe a Star Wars ship to my team, and they had to build it from Lego.  Yup - we were back in "describe the starship Enterprise" territory as above.

For the first round - describing Luke's landspeeder, I just played along - "it's a vehicle like a bath tub, with half way down sitting for two people behind a glass windscreen ... there is a rocket either side at the rear, and another one above on a strut".

In the second round, the subject was now a pod racer from The Phantom Menace.  This time I decided to using my mother's teachings - I'd not describe in detail, but I'd give an overall impression of it and "leave it to the team to be inventive".  We'd actually been on a tour of Weta workshops recently, and it seems when a director such as Peter Jackson or James Cameron ask for a prop, they tend to explain what it does, and overall look and feel, but the fine detail is left to the designer ... because he's a designer and designing things well is what he has experience of.

And hence I went to my team with this, "I'd like you to think of Ben Hur ... in space.  Imagine a sci-fi chariot, only instead of horses, it has these two massive, and I mean giant rocket engines.  And tethered behind is a small cockpit being dragged behind by the poor guy brave enough to pilot this thing".  The team loved the challenge, and what they built really looked amazing (damn that I didn't take pictures).

There is of course a point of this, and it links back to testing.  Throughout this year we've been discussing scripting - when it's useful, and when it's not, together with the question of detail.  A lot of people will say "include a lot of detail, because then it leaves nothing to chance".  But although you can read my starship Enterprise description and agree it's technically correct, at the same time it's just not very helpful at all.  On the other hand, Douglas Adams in The Hitch-Hiker's Guide To The Galaxy described the starship Heart Of Gold as "a sleek white running shoe".   And I tend to think what was good enough for Douglas Adams ...

For me a real awakening came in 2003, when I happened to be in a test lab during UAT, and heard someone reading aloud a script I'd written in 2000.  I'd come off an automation project, and felt that "loads of detail = GOOD".  But hearing it, knowing I'd written it, my heart sank, because it was dreadful and overdetailed.  Knowing the system better now than then, about a third of the description was really necessary.

This is why we live, we learn, we do better next time ...

Yup - I really did think is just this much detail ... but did a reader really need to know it?

Yup - this was how I described the starship Zeko at first.  A couple of years later I'd got better, and described it as  "a large, city sized disk, bristling with so many terrifying weapons".  Which I bet you can read ...

Because if you're building a ship that big, you're not going to walk ...

Voices From The Past 1: Introduction

Over the last couple of weeks we've been doing a garage and storage clean up.  I know we're not alone in storing personal items way past their "sell by date".  Hence it's time for a good clearup of items, some destined for sale or for dumping.

"What kind of things?", you ask.  Well I've found some VHS cassettes (we don't have a player any more), boxes of video games we kept "just in case" (we don't have the original game system), some old computer bits and pieces (128MB memory anyone?) and a text book on Fortran 90 (yeah Fortan ...).

What I was really excited about though were a set of old exercise books that I found which have various ages on them.  The oldest date back to when I was 13, some are from University, and others "relatively recently" after the birth of my son.  Sadly there was a couple I'd hoped to find, but they may well be MIA.

Some were short story attempts, some were lab notes (with poems in the back), some were role playing campaign designs.  I'm happy to see them all and reconnect in different ways with my past.

Most interesting to me though are the journals I've tried to create, and often been unsuccessful.  This wasn't helped by me keeping a diary during high school which got stolen, and basically the details passed around.  Ironically these days through this blog I probably live my life much more openly than anything I'd ever put into my diary back then - probably because age has taught me to not be afraid, and I realise sometimes you need someone to come out and be open about some of the key subjects I've chosen to talk about (thinking here about my mental health series).

Looking back at anything you've written over a decade ago has an element of fear around.  I know in testing over the 4 year life of this blog I've found my own attitude and understanding of testing has changed.  I'm sometimes tempted to go back and change or even delete some entries - I found this recently when I reposted The View From The Test Manager's Gallery which was originally published in Testing Circus in 2011.  There are subtle changes I'd make to that piece, especially the slight emphasis of metrics, whereas today I'd call it "reporting".  We live ... we learn.

But to my surprise there are things there that I've really enjoyed writing, and even worthy of looking at on this blog.  And hence this series where I look back at some of my writing from the past and either repeat it, or else analyse how it impacts me in the present.

What has surprised me reading - although I've only been writing about testing for 4 years, I've been trying to explore the big picture of "what is important, what matters, what is truth?".  These are good questions for testers - testing is about being the philosophers, scientists and explorers after all of the digital world.

Enjoy ...

Saturday, December 6, 2014

The View from the Test Manager's Gallery

This article was written back in 2011, and first published in Testing Circus.  It's an article I've always had a lot of affection with, because it was my attempt to rationalise my first steps into a test leadership role.  I found a lot of it was spot-on with where I'd continue to develop, however there are a few things I'd really like to change - for instance today instead of saying "metrics matter", I'd go "reporting matters".  But at the time I was for the first time seeing how project managers were using our reporting and circulating them up - the pain those reports could bring was becoming more visible to me than in my roles previously.

An interesting trivia point - this article was originally written for the Ministry Of Testing's Testing Planet magazine, but was rejected.  Which felt a little awkward as I was assisting as an articles editor at the time (hey, you can say for sure it wasn't a clique).  I say this not out of any ill-will for Ministry Of Testing, but just to make clear that we all suffer the odd knock-back at times.  In fact the next piece I wrote for Ministry Of Testing I got fabulous support editing from Simon Knight on, and the article produced, "The Software Minefield" would become the name of my first collection of articles.

The View from the Test Manager's Gallery

This year has been one of change for me – the much sought-after promotion to test manager finally happened, and with it a new set of challenges.

Several months in, I realise that although a good test manager does need to be a good tester, the skill-set and emphasis is different in many ways to that of being a senior tester or even test team leader.

Indeed, I’ve learned that the view from the test manager’s gallery is very different from that on the factory floor of testing …

You need good people

Several of the areas that have needed testing this year have been new projects, with no allocated staff for testing.  Thankfully there are several very capable test consultancies who'll send me contracted test resources.

Ticking off the details, two of my new projects were customer facing - the kind your average man-on-the-street should be able to walk in and use, with no documentation required. Systems integration testing was being done elsewhere, and we would concentrate more on usability testing, that the interface functioned “as designed”.

So I reasoned with no real needed knowledge, I could use anyone really to perform this testing, the more junior and cheaper probably the better for my project manager (who'd be picking up the tab).  The tester I ended up with was not junior, but one with more testing experience than me.

Not what I asked for, but in hindsight something I’m very thankful for - you see, I'd planned for myself to be a lot more hand-on during the test phase, overseeing what was happening day-to-day. The reality (and the best laid plans of any manager often go this way) was that when testing started (there were some delays getting a working build to us) I had another project to work on which thanks to timescales moving (test managers should be used to this) meant we were doing our best to try and get two projects tested concurrently.

So what did Brian, my experienced tester bring to my project? Being experienced, he had worked on enough projects to need minimal supervision – I set out for him on the day he arrived what I needed to do, what our testing objectives and requirements were, who the key people were, and a couple of test script samples for him to copy the style and get him started.

He went away and created the rest of our required test scripts, and got testing. Overall he used his own initiative, would inform me of his progress and any key issues/decisions, and generally “got on with it”.

With a more junior tester (as I'd requested) I'd have expected to have needed to be much more hands-on, overseeing their work, to the determent of my other project. Instead we had clear objectives, and a framework for success passed to my tester, and they used their initiative to achieve that result.

Taking a step back

As a senior tester on past projects I usually felt obliged to take on “the hard stuff” of a project, the difficult technical testing, to leave the easier stuff for the junior testers.

Likewise as a team leader last year, I felt an obligation to do the hard items myself due to my increased exposure to the technical meetings, and let the rest of the team pick up on the rest.

I realised though there's a big issue there when you step out of the role of senior tester and towards team leader or test manager. The issue is one of control-freakery. You're taking on the tough stuff to go easy on the team, but in doing so you're also showing a distinct lack of trust and respect in the abilities of your team. You're saying some parts are beyond their skills, and setting them to fail before even giving them a chance. How can the people in your team really grow if you don't give them some challenge?

I realised this when I reviewed Brian's completed test scripts. I liked them, they achieved the desired results, but … a small piece of me felt a little unhappy with them. The reason? Because his scripts were not quite how I'd have done them myself.

After a quick ego check, I realised this was something I'd have to let go. The scripts were good, and just because they weren't quite how I'd write them, it was no reason to have parts of them redone. That's petty and doesn’t matter, as long as the end result is a good testable script.

It's like when you make a cup of tea for someone, they sip it and mmm they say it's a nice cup of tea. They then ask “did you put the milk in before the water?” and you say no. They then get quite upset saying, “but you should always put the milk in first”. Does the method really matter if the end result is still a nice cup of tea? With some people and some managers it really does – they often are the worst kind of micromanager, the kind we all hated working for ourselves, and ironically the last person we wanted to end up as!

Metrics Matter

I used to get annoyed with my test manager a few years ago when he bugged me about metrics. Running around booking metrics figures felt like it just created delays, and stopped me from actually testing.

But the fact is that metrics matter.

Let's face it, testing is always the last phase before a piece of work “goes live”. Invariably a piece of work enters testing late because the development took longer than expected.

So as a test manager we often have to deal with an expectant project manager or business owner who wants to know if their target go-live is still achievable.

Metrics are an important part of this. But they are just a part. Together with any metric or graph, there also has to be an analysis of what it means. Otherwise management have a nasty habit of seeing trends in your numbers and graphs which just aren’t there.  This mastery of metrics is an important part of the test managers role, and they can be useful or a hindrance.

A discussion on metrics and communicating to management could be an article in itself! But there are a couple of general topics to be covered,

  • the progress made through test scripts
  • defects unresolved, especially “the big ones” which are high severity and we should not go-live without
  • an action plan on the “big defects” if you have one from your developers
  • an explanation of any impediments that have affected the day, such as the system being down all morning due to connectivity issues.

Management are a busy lot, and they get a lot of emails. I find that it's useful to send them these daily reports, but also to catch them a couple of times a week, and verbally given them the 2-minute summary of how it's going and what the “big issues” are.

It's useful too as during an extended test period you're sending these emails everyday, and no-one really ever seems to respond to them. So it's nice to have feedback that people are aware of the issues and risks you're flagging on a daily basis.

So the big ticket items I’ve learned to date?

In summary, it's important to have staff who can as much as possible “get on with it” and use their initiative. But you won't keep that kind of resource if you never allow that tester the authority and space to make those kind of decisions.

But as a test manager you also need to realise your role has changed, you're taking a step back from the testing factory floor, and trying to support your test team – attempting to hussle to get a test environment, design specs, software releases – to allow them to do their job. But also to tell your test team’s story, you need the dreaded metrics to communicate to management and business owners how soon they'll have their shiny-tested product in the market.