Returning To Test Estimation ...

A couple of years ago I touched on the subject of test estimation in my article Those Darn Test Estimates.  Following a recent conversation with Jari Laakso I found myself wanting to return to the subject.  Why?  Because although at the time I was happy with that article, today I find the article isn't good enough, the reason being that in the time that's passed, I've learned a few things ...

We are told that as testers the most important relationship we have is with developers, and whilst that's true for junior testers, as we take on more leadership of our team, things change.  Increasingly as we get senior it's our relationship with the project manager that becomes more and more key.  Oh, the rest of the team need to keep networking with those developers, but you become the key relationship point between the project manager and the test team.

For that relationship to work, it's important to know what matters to project managers.  Many people when they start in software testing think project managers are only interested in two things "hours booked" and "percentage done".  Do not be fooled!

Over the last two years at Kiwibank I have been very lucky to work in a business unit of project managers, business analysts, market managers and business owners.  As Dian Fossey did with gorillas, I have managed (through the miracle of co-location) to observe business people in their natural habitat, and in the process learn more about them.

But even that hasn't been quite enough.  To understand more of what I heard and what I saw, I used Johanna Rothman's Manage IT guide for practical project managers.  Not because I wanted to become a project manager, but because I wanted to understand them and their processes.

And so this, in a basic nutshell, is what I learned.  Project managers have two main focuses, which although they link in with "hours booked" and "percentage done" they are not "hours booked" and "percentage done".  They are,

• To manage the budget and timeline of the project.
• To manage the risks linked with the project.

The risks are important - in fact, project managers keep a register of risks much like we keep registers of defects.  There they list potential pitfalls, how likely they are, and how significantly they could impact the project if they were to occur.  Multiplying the likelihoods with the impact gives a list of the top risks, which the project managers focus on.

With that in mind, lets return to the subject of test estimates, and see how we can work more on the same page with project managers in the domain they understand.  Of late I've worked with a project manager named Annabelle, and we've thrashed around our recent test plans until they've worked as below.  It's been a positive relationship, and has really allowed me to see much better how elements of my plan are used,

Estimates - the good, the bad, the ugly

The starting point it to look at the project, the general scope, and just trying to size it up.  There is probably some absolutely fabulous formula out there to do this.  But I think there's just no substitute for past experience.

What past project does this most likely feel like?  Don't be afraid to ask around people to get their experiences as well.  Listen to their stories of how their past projects took more or less time that you experienced in any parallel projects of yours.  Where is the complexity?  What will slow us down?  Are processes we're testing instantaneous, overnight, monthly?  How will that affect how we test?

By now you should feel split three ways on three possible scenarios; "well if everything went perfect", "I guess we might have a few bugs and tests to redo, we normally do" and "OMG, we're screwed".  From Those Darn Test Estimates, that's what we'd normally call Best Case, Probable Case, Worst Case.

But wait, we're not finished ...

Now here's where we can have a meaningful dialogue with our project manager.  I'd always put into any plan a list of my assumptions, but the genius suggestion from Annabelle was that I add a column which said "Impact if wrong".  If my assumption was wrong, what would it mean for my plan and my timescales?  What would have to be redone?

To me this was a game changer, and suddenly I realised I was helping to communicate more to my project manager in a much more direct manner than asking Annabelle to "read between the lines".  Suddenly from a dry list of assumptions, a few of them would stand clearly out, because anyone reading can clearly see "well if they're wrong, this is going to hurt".  This inevitably leads to a conversation around "well how can we get more information to check this assumption or monitor it?".  Suddenly people are being proactive, over waiting for issues to happen.

This of course leads to the issue of risks.  Actually the word is such an important one in software development, it needs a capital, exclamation marks and all kinds of funky formatting ... Risks!!!

It was only recently I had the revelation that when I'm giving a list of risks (with likelihoods and impact of course), what I'm telling to my project manager is this 'these are the factors which will push testing onto the "Worst Case" time estimates over the "Probable Case" ones'.  If you think your project manager doesn't understand this, make it clear by writing that very statement near your table of risks.  It's something we sometimes take the danger of implying, but it needs to come out on the table and be made clear to all involved.

Now, us those conversations you had with other people to help you fill in these risks.  On a first draft, you should really throw to a larger group all the risks people have thought of (if your project if big enough, maybe workshop it), sometimes something that sounds innocent gets someone else thinking "wait a minute ...".  It's important to capture as many as possible, and then truncate and collect into themes.

Like with assumptions, once collected, a few will really just stand out with an "ouch factor", and no doubt make it into the project manager's risk register.  But they're not just there to be something you fall back on when things go bad "look, said it might be a risk, turned out it was".  They, particular the "ouch" ones, are something to be proactive about.  How can you tell early if this is happening?  What can we do about it?

Lets look back at some of the risks I identified first time around, and see if we can be more proactive ...

Software Delivered Late / Software Delivered Is Of Poor Quality

What testing is development planning to do?  Can testing get early copies of software to get a feel for what's being built?  Can testing talk to development about the testing planned to help development in their unit testing?  Can testing get visibility of the testing developers plan to perform for unit testing?

Notice all of these are about dropping the silo mentality between testing and development and working closer together over a passing of baton between development and testing phases.

The Delivery Chain

How can you get developers and testers working closer together, especially if you're not co-located.  How about a daily catchup even in phone conference?  Throw in video if you can (it's the 21st Century after all, and we work in IT).

If the software development is done out of country and you only get weekly builds, can you get the development to try out scenarios on your behalf?

If you are getting weekly builds and the software prevents basic testing because it's so buggy, can development prioritise on those key bugs and get a fix over asap?

Time Erosion

Keep a log of all the meetings needed.  Does everyone need to be at these meetings?  Are you getting value when everyone attends?  Some form of daily meeting can be invaluable, but most people will only need that one.  Leaders can attend other meetings on the teams behalf, and feedback anything key to the rest of the group, likewise providing information up the chain from testers on the ground floor.

It goes without saying - don't try and to major testing sprints over major holiday seasons, and try and work on personal appraisals before/after scheduled busy times.

Requirements

James Bach in his Rapid Software Testing course calls requirements a form of Oracle, or "model of how software's supposed to work".  An Oracle sets up an expectation of behaviour, so when we do something with software and it goes against our Oracle we know "well that's not right".

Requirements are the most obvious "model of how software's supposed to work" that we usually encounter but there are other kinds of Oracle as well.  Can your team,

• Talk to the business owners who put forward this project?
• Talk to end users about what they'll be doing with the system?
• Talk to a subject matter expert?
• Try out similar products which are already out there on the market?

All these things help testers build up a sense of "what the product should do, and what behaviour matters".

Novopay - the tale of a compelling event in the New Zealand IT industry

Open almost any book on testing, and it will start with a "cautionary tale" about software testing, where something was released into production, and it went wrong with devastating results.  They are the ghoulish "tales around the campfire" of our IT industry.

One problem I have found within the New Zealand industry is that as testers we love to focus on anything that goes "bang" and crashes.  In 2011, I was in one a talk about software testing to a group of new developers as part of the Summer of Tech, where our introductory speaker spoke of an Ariane 5 rocket where the parts had been individually tested, but put together into a new rocket.  As you can imagine, this rocket barely cleared the launchpad before it exploded. Another cautionary tale of "you didn't test enough".

What's interested is what happened next.  One of the audience interrupted with "but we're creating applications ... not rockets.  Our stuff is hardly critical like that".

To me, this reinforced how vital it is to have stories and tales of failure which are relevant to the audience.  I thought the tale was a wonderful one, but looking around the room, I saw it failed, because the audience simply did not believe it applied to them.

New Zealand is a small and very pragmatic country.  A lot of processes here are still fairly manual compared to my home country of England, and overall that's not a bad thing.  Here in New Zealand if something isn't broken, New Zealand attitude is "why try and fix it", so,

• In the UK for trains we have automated ticket vending machines (usually vandalised), automated turnstiles to get onto platforms etc.  We used to get told our ticket prices would have to go up above inflation to cover this automation and it's continual repair.  In New Zealand they just have an old fashioned conductor on the train who checks and clips tickets, and can sell you one for cash if you need one (without charging a fee).  Simple, but y'know it works.
• In the UK there were plans to build a so called "chip and bin" system for collecting rubbish.  The UK rubbish collection vehicles would scan your bin, which would then be weighed as it was disposed of.  Back at the main office this data would be collected, and an itemised bill created (your bill would have to be more to cover all this new technology which would have to be developed and maintained).  Again being super pragmatic, New Zealand councils just sell you council marked rubbish bags which have a charge on them for collection.  Only rubbish in council bags is disposed of.  The more you throw away, the more bags you need.  Elegantly simple yes?

An unfortunate by-product of this pragmatic way of doing things is the attitude of "she'll be right", which means if something goes wrong, don't worry, we'll be able to fix it.  This means on the whole New Zealanders can be a little bit more risk takers than their European or American counterparts.

In a testing consultancy I previously worked for, my test manager would talk about how New Zealand would have to face an inevitable "compelling event" for software testing.  Most other countries have had one, but so far although there had been failed there hadn't been one in New Zealand.

A "compelling event" is something that forces you to take action - a wake up call the the importance of the value of testing.  A compelling event isn't just software going bad when it hits production, it's software causing a very large and public pain that it unnerves the local IT industry as a motivation to not repeat that mistake, often with a gasp of "that so easily could have been us".  It's not a rocket blowing up half way around the world, it's software that fails but feels too close for comfort compared to what you're doing right now.

It's a compelling event because once it's happened it compels you to take a good hard look at your strategies around testing and quality and ask "are we (and not just testers here) doing enough?".

Sadly, we've finally had our big compelling event here - the Novopay saga.  Novopay was an online system for managing the payment of teacher and school staff salaries.  But sadly it has gone into production to go horribly wrong, with payments to these people missing in the system.  There have been schools where teachers are missing months of pay (and teachers aren't exactly in the most affluence of careers).  More than just being "missed payments", there have also been erroneous payments gone out from schools - some teachers who've never worked for a school, are receiving payments from that school - and schools are having to bring in extra staff to go through the Novopay payments with a fine tooth comb to work out what's payments are good, what payments are errors and what payments are missing.

The media have been in a frenzy over it, hounding senior staff at the Ministry Of Education (who are behind Novopay) saying they have found a report of "200 known bugs" in the production system when it went live.  It is terrifying to me as a senior tester is how bad that sounds when the media put it like that.

Of course when I worked on an avionic computer, it'd surprise people to know it flew under the strictest of safety conditions, but still there were 1,500 known bugs in the software.  The important message though isn't the bug count, but the severity.  But this is a very difficult dialogue to have with a set of press hounding for a "big story" and "potential coverup".

In an unusual move, the Ministry of Education has released the test plans for the Novopay project into the public domain.  I took a look through, and they show a fairly thorough planned approach was taken to testing, not the slap-dash "rush into production" that many in the press are claiming.  That was pretty unnerving - most of our "testing horror stories" like the Ariane rocket involve people simply not testing, thinking it would be "alright mate".

The documentation they have also shows a decent approach to several forms of functional testing, indeed going beyond what I would have initially thought to do,

http://www.minedu.govt.nz/theMinistry/NovopayProject/NovopayTestPlans.aspx

However for all it's success in testing, something has gone very wrong in production, there can be no doubt about that.  And it is causing real grief to people whose life it should be easing.

What went wrong?  Each of us will have our opinions about this, and no doubt all of us will be right to some extent, whilst at the same time knowing in our hearts how easily something like this could happen to us.

Testing is about identifying and helping to remove risks, but it does not guarantee a bug-free product.  We can test in the many different ways we expect our software to be used, we can check for all the problems we can imagine could happen.  But that will never cover everything, there will always be issues beyond our imagining.

But the imagination of any individual has it's limits.  We have to be careful not to find ourselves screaming "inconceivable" at every bug found in production.  In my opinion, this is why testing and quality is not just a "test team" ticket.  We need to be engaged with developers, business analysts, market managers, usability experts, end users to work out a whole scope of things to test (from areas of functionality to ways of using) that is beyond the imagination we as testers can summon when looking at requirements.  But by then our scope of testing has probably increased by several orders of magnitude, and we don't have unlimited time.

That's when we need to do some risk based analysis, and cover as much of it as possible, touching on all the "most likely" cases, then touching on samples in other areas.  If you find problems, then odds are there'll be others, so keep looking in that area.

For myself then , if there is a compelling lesson to be had from Novopay it is that we need to draw up our test plans as we always have done, and then ask of others "what could I have missed".

An offer you can't refuse ...

I have been a little quiet on my blog this year - however I've been far from idle in 2013.

I've put a lot of work into writing and expanding my book The Elf Who Learned How To Test, which got very addictive writing for, and now includes 4 stories, and "the story behind the stories".  It has been an absolute blast writing something a little different, and I've really enjoyed reading the tales to my  teenage son Cameron.

Beyond that, I'm now looking forward to starting a new position in April at another company in Wellington, Datacom.  My role there will involve a lot more working with, leading and developing testers.  As you can tell from my blog, it's something I'm passionate about.

I have learned so much since coming to New Zealand.  My time at Test Consultancy Assurity taught me so much about championing testing and what testing does well.  At Kiwibank I have thrown in my lot with a fantastic group of people, where I've learned about testing's relationship with other departments and been lucky to not be a tester in a testing department, but a tester in a multi-discipline team, learning the aches, pains and victories of project managers, business analysts, market managers.

What's so exciting about the, is it feel like all my effort in writing the book The Software Minefield, I have laid down a baseline of ideas and approaches I'm hoping to find opportunity to tap into.  To celebrate this, I'm offering the book free until 1st April 2013.  All you have to do is click to buy the book, and provide the coupon code, "sZSRStQO6r6C", the book is then yours to enjoy free of charge.

Happy reading, and if you enjoy, please promote and even write a review!

Meditation to beat those stressful days ...

Without doubt we all have experienced stress in our working life. When I was training to be a teacher at the University of Sheffield, and we were taught some very basic Alexander technique and meditation skills towards the end of our course.

What I find interesting moving from a career in the teaching profession to the software profession, is how this subject rarely seems to be talked about and addressed. You might be lucky and have a company where someone on level 10 is running a meditation or yoga lunchtimes, but many places don't.

I myself have been been surprised that some close friends (in and out of my profession) don't know the basics of meditation and it's benefits, so I've felt this a topic long overdue for discussion on this blog.

What I aim to do here is give a quick description of meditation, separating the fact from voodoo, and set out a basic exercise for you to try if you've never experienced it before.

Stress – a very modern problem

I have a remarkable memory, except when I'm stressed, when my brain becomes a leaking sieve. Why?

When I'm stressed there tends to be a lot going on, a lot of things I'm supposed to keep my eye on the ball with. I might be worried about someone in my family, we have a deadline, things in my personal or professional life is going through a tough time. Hey – this is life, stuff happens and stuff builds up.

The problem is, with so much to worry, this worry forms thoughts that circle and circle around your head like sharks, forever distracting us. We can't concentrate or even sleep, because we can see their fins as they circle around our mental raft. We can't help it, it's a subconscious thing – the more we try not to think about the sharks out there we're seeing the more aware we are of them.

So meditation?

This is where meditation comes in. Basically meditation helps us to banish these worries and stresses not by trying to send them away, but diverting our attention to something else.

Have you at any time reading this blog thought about the breaths you've been taking? Of course not, breathing is a subconscious function – it happens without us thinking about it, which is why we don't suffocate when we go to sleep (which is pretty handy).

All meditation works by shifting our conscious focus to our breathing, and by doing this, all these other things get blurred. Once you start to think about your breathing, you find it's hard to pull your consciousness away from it. Even now you're so much more self-aware of each breath you've taken since I've mentioned – possibly to the point when if you're distracted by a spelling mistake it almost feels like you're forgetting to breath. So please right now … remember to breath.

In a nutshell it's really that simple – focus on breathing. But by giving ourself time to shift the focus and banish these stresses (even for a little while) it can calm us enough to focus our minds outside of meditation, or just feel more settled to be able to sleep.

A basic exercise

Okay – willing to give this a go? I have come up with a very basic exercise here, you'll need to memorise it, and give it a try – if it works for you once, return to it another day, and keep practising.

First of all, try to find somewhere comfortable – many find lying down helpful, buy an armchair will do just fine, and try to be somewhere where you'll feel warm, quiet, and where you'll not likely be distracted. You need to give this your full attention, so obviously don't try whilst driving or using any equipment (safety briefing over).

Are you comfortable? Then we'll begin …

First of all you need to just just start by focusing on your breathing. Breath in through your nose and out through your mouth. Just keep doing this for a while. Feel the rhythm of your breath, and try to breath deeply from the bottom of your diaphragm. Each breath should, feel slower, slower than the last. There should feel no urgency, you may even feel your own heart beating as a rhythm as each breath seems to last longer, and you feel your body relaxing.

With your eyes closed I want you to take a breath in and visualise the number 10 in your mind as you breath out. This isn't a race, let the breath flow softly and naturally. When you reach the end of it, take another breath and visualise 9 as you breath out. Keep this going, in through the nose, out through the mouth. Slow and deliberate with every breath. 8. Feel each breath longer than the last. 7. Your body feeling the stress and tension exit with every exhale. 6. Your body should feel relaxed, but somewhat heavier now. 5. It all feels comfortable, you feel at peace with each exhale. 4. You are almost there, where you need to be. 3. Continue to breath, feel the movement, ebbing and flowing like waves lapping a beach. 2. Imagine you're on a beach looking at these slow waves of breath coming in. 1. You are there, sitting on the beach, the waves slowly lapping on the shore with each breath you take. Watch them come in and feel and anticipate each wave. You feel quite comfortable where you are, there's no need or desire to be anywhere else. Just to breath in and out, and watch each wave as they comes in. Feel the rhythm, feel it slow and natural, hear in your mind the gentle rumble of each wave in unison with your breath.

When you are ready to leave though. Count the numbers back visualising each in turn. 1, 2, 3. As your body starts to feel awake. 4, 5, 6. You feel yourself shifting now, becoming more aware of the room around you. 7, 8, 9. You are almost back, you're thinking less and less of your breathing, and more about the details in the room around you. 10. Welcome back.

Hope you enjoyed.

How was it for you?

You might have found that didn't quite work for you – maybe you couldn't get comfortable, or were distracted during it. Even basic meditation can take a few goes, but please give it another try out. Maybe try some soft music and pleasant candle smells to help you relax. Lavender is a good smell for relaxation.

If you found that worked for you, welcome to the world of meditation. Keep trying the exercise, try and get comfortable with what happens, and try experimenting with it. Maybe look up some other exercises on the internet. Instead of a beach, maybe think about your favourite place in the world, and imagine you are there. The possibilities are endless!

Remember, you don't have to be a hippy or a spiritual shaman to try this and get the benefits of it. If it works for you, pass it on. I believe it's the vital piece of an office workers toolkit to have this. On important or big days at work, find a few minutes before a big presentation or meeting to do this to calm yourself – it can work wonders.

Happy stress busting everyone!

The New Year retrospective

If you are like most people in the world, as the clock ticks down to 12 on 31st December, you are probably preparing a couple of New Years Resolutions.

This in itself is no bad thing – we should be aiming to improve ourselves and what we can achieve each year.

Some of these resolutions will be about our fitness (especially post-Christmas), some will be about our personal life, and some our work life.

I like to thing really any resolution is about really wanting to address an area in life we feel we're not doing so well in. In order to do that we have to use the time coming up to 2013 looking back on the year.

We held a few retrospectives at work in 2012, and I found them overall positive experiences. We looked at the “positives” or what we'd done well, and also the “deltas” areas we need to improve in (notice we don't call them negatives, we are trying to positively look at changes we can make).

In the same way we need to look for those areas of change in our life, and decide to do practical ways that we can make change.

Back in March in the SoftwareMinefield, I was talking about people's resolutions, especially when it came to learning (a key subject in the book), and suggested whether in learning or elsewhere, the best kind of resolution was a SMART resolution …

Learning like diets is one of those things we often attempt to resolve to do more of. So like our New Year diets often involve "only eating salad and soup until Easter", our learning plans often go down the same "too ambitious" route ... "I'm going to read a book on software each week". Good luck on that!

Like any good plan, you need to have objectives, and they need to be SMART objectives. My version of SMART here being Specific, Measurable, Achievable, Realistic, Time-bound.

• Specific - what do you really want to learn about? Testing in general? Test automation? Agile testing? What channels are you expecting to use? Courses, books, magazines, forums, Twitter?
• Measurable - how will you know if you've made progress? This one is tricky when it comes to learning, as short of "taking a test", it's difficult to do. But it's important that you feel you're making some form of progress. It might simply be that you find yourself reading articles regarding a topic, and finding yourself more comfortable with the arguments than a year ago.
• Achievable - is it possible to achieve your learning goal with the resources you have? Do you need more to achieve your goal? If you are planning to read a specific book, do you own a copy yet, or can get it from the library? If you are trying to learn about a certain technology, can you get hold of a sample of the application to aid your study?
• Realistic - as I've said, it's got to be realistic. Your friend John might be able to give up 2 hours every night for study, but you have family commitments, and you can't match that. What can you realistically commit? An hour a week? An hour a month? Be wary of making a rash overcommitment, but also make sure you are actually putting the time in.
• Time-bound - you need to revisit your aims and objectives. Set yourself a realistic time-scale to achieve in, and re-review what you've achieved and your future direction after so long. You set yourself to learn about Test Automation, but after 6 months found yourself reading more about Exploratory Testing. Should you go back to trying to study about Test Automation, or continue with Exploratory Testing? Remember they're your goals, but if your aim was to learn more automation due to a drive at work in the field, maybe trying to refocus on Test Automation is something you need to do ...

So before you start making a resolution in the New Year countdown, ask yourself, how can it push you, and yet be sufficiently sustainable, so that you're not embarrassed come April when people ask you “well how did that work out for you?”.

Last year I famously talked in my New Year about “why Superman must die”, meaning to be effective at work I knew I needed to gauge my limits and know when I really needed to stop myself from trying to help someone, simply because I was taking on too much. It was a post which continuously challenged me, and I have to admit it I don't think I always got it right on that score.

I was much encouraged by emails from my friend Bernice Ruhland on the subject, but also by a wonderful talk by Johanna Rothman on “when to say yes, and when to say no”, which so moved me it led me to get in contact with her and thank for for it.

Yes 2012 has been an emotional journey at times, but I've built up some great friendships to see me through the rough parts ...

So you want to move abroad?

This year I have received a number of requests  via various channels from people who have learned I migrated to New Zealand, and want to know more information about what's involved. I'm happy to help or at least direct where I can, and have got to know some of them quite well in the process.

I myself several years ago was in the same boat, and really relied on the same goodwill to understand the journey I was about to put myself and my family through. But just as a future resource, I thought it might be useful to write up our families experiences.

My life before migration

I graduated from University in 1992, and I have always had the experience of having to “move to where there is work”. Part of it was an after effect of living through the Miners Strike of the 80s in Great Britain, where pockets of high unemployment came about, and the only choice for many was to uproot and move to where they could find work.

So I found myself taking quite the gypsy lifestyle,

• working as a teacher in Keighley, Yorkshire
• doing a Masters degree at the University of Essex in Colchester
• doing a six month research post into laser holography at the Friedrich-Schiller University in Jena, Germany
• doing a years research into Optoelectronic Monitoring at the Electrical Engineering Department at the University of Liverpool (where I met my wife)
• my first software job at TMSL in Weymouth (for 3 years)
• moving to Farnborough, Hampshire to work for EDS and BAe for 10 years

Moving is painful. It means leaving behind friendships and often starting again. My wife who'd always lived in Liverpool, and whose whole family still lives in the same suburb, found the first few years living so far away from her family a difficult experience (and that was 200 miles, not half way around the world). It echoed my own experience when I lived in Germany – I found living so far away and not being able to just “drive home” very difficult, especially when coupled with culture shock about living in another country. However over time I adapted, which is a key and important thing to do.

All this was really important, because it said to both me and my wife that we could cope and adapt to change.  My experience in Germany showed me that I struggled when we were in an atmosphere where English wasn't spoken, and doing our homework on New Zealand based on some friends who had migrated from there, it seems an ideal candidate for us.

So you want to move abroad?

So this article will be threaded with warnings – and here come the first one. Migration is not an easy process or a “certain” process. It will take time, and importantly, it will cost you a lot of money. Moving abroad is not a cheap thing to do, and in New Zealand I don't know of any company that funds it for you (in case you were hoping).

One of the most important things is to be realistic about the reasons you are looking to move. We all feel a bit that “in our country we're being ripped off... life is so much easier in [insert name here] country”.

Well let me tell you right now, EVERYONE in every country feels that about pretty much every other country,

• people look at America, and think “wow your supermarket and phones are so cheap”. But your average American is going “cripes the cost of healthcare in this country is ridiculous”.
• people look at Australia and think “wow, look how much they earn compared to us”. But your average Australian (especially in Sydney) is thinking “good God, the size of my mortgage repayments”.
• people look at New Zealand and think “wow the house prices are cheap”. But your average New Zealand is thinking “why is the milk and food we grow here more expensive here than when the same food is sold in the UK or Australia?”

The bottom line is, if you think another country has it easier than you, try and befriend someone who lives there and ask them what they love, and what they dislike. Try to see the whole picture.  In particular, if you meet someone from that country living in your own, ask them why they moved. Try and take off the rose coloured glasses and see it warts and all.  If you are not seeing problems with moving there, then I tell you that you are missing something.

If you are thinking a move to another country is going to solve all your problems, you are in for a nasty shock. Do your homework, read as much about this place as possible. Try and read up the local news and concerns. If you can, go and visit it to see it for yourself – however beware. I used to live in a seaside town most people would think “wow it would be nice to live there all year around”. But even being somewhere on holiday is vastly different to living there.

Try and draw up a list of thing you'd feel would be improved by moving abroad, together with the things you'd miss. Don't forget to try and factor in things like friends and family into that. Ask yourself, do the pros outweigh the cons?

If you have done all this, and you still think New Zealand is for you, then read on, and I will talk you through the the stages that await you.

Lets Move to New Zealand

From our own story, we made the decision to move in 2006, and finally moved in 2009. For many people at least a year between making the decision and finally arriving is a minimum. You're not going to just fill out an application and be on a plane 2 weeks later. This is the reality.

To move to New Zealand for many people is a two-stage process. To come into the country you need a Work Visa. But before you have done this, you need to have filled in your Expression Of Interest.

An Expression Of Interest is a form you submit to the New Zealand immigration office that expresses your interest in migrating to the country. As with most stages of the migration process, you need to pay to have your form filled in.

In it you detail your personal details and relevant experience, as well as confirm you have no criminal convictions. If you do have any criminal convictions or major health problem, it's going to get phenomenally difficult (if not impossible) for you to move here. The Expression Of Interest allocates points against certain traits like qualifications, experience, age, personal status to weigh your eligibility to come into New Zealand, and can be a stumbling block to many aspirations.

Once processed (which takes several weeks), you are given the details of your weighting. Some lucky people are told they can proceed straight to “applying for a Work Visa” which allows them to come to New Zealand and look for work right away. But for myself and many others we were told we were elligable for a Work Visa as long as we had a supporting job offer.

For either route, it's a mistake to believe at this point you can start packing your bags. The application for a Work Visa is a much longer process than an application for the Expression of Interest.

Needing A Job Offer

Well this is definitely a difficult path. The easiest and quickest method is to approach a few employment agencies, fly over to New Zealand (on a visiting visa) and do a few job interviews. But it is far from the cheapest.  Indeed because you've arrived on a visiting visa, even if successful you typically need to leave the country and re-enter with you Work Visa.

Talk to as many recruitment agencies as you can (Google is your friend here). Some might know some companies who will consider you based on phone and Skype interviews. But the harsh truth is many will not. It's important to tell them you have a successful Application Of Interest, and this does help.

Applying For A Work Visa

So you have all the conditions on your Expression Of Interest, including perhaps a job offer. So it's a done deal then?

Sadly no, far from it. There are still a considerable number of immigration hurdles to clear.

First of all you have to compile together a Work Visa application – which means another cheque to be processed. To support this you will need also have,

• a medical for each member of your family performed by a private doctor approved by the New Zealand Immigration board. This will also include a chest X-ray, and you will have to cover the cost of this yourself.
• a Police background check, which again you will have to pay for.
• copies of any qualifications to be evaluated.

Once all this is forwarded on, its a process of typically at least 3 months before you're approved by your local New Zealand embassy. Sometimes you will be asked to provide more information or checks, which will cause additional delays to this timeframe (I did mention it wasn't going to be a quick process). As a word of caution, I've known friends who have encountered significant delays at this point (it took 6 months for us ourselves).  It's frustrating, but moving country is a big deal, and the immigration office have a duty to be thorough about who they are letting in the country.

You can help the whole process of the paperwork for the Application of Interest and Work Visa by hiring an immigration specialist to advocate on your behalf. These can be expensive, but it's worth shopping around – you won't want the cheapest, but there are some parties out there which in my opinion are out to fleece would be migrants (we encountered a couple ourselves).

Alas there was one such company I'd recommend but sadly they've recently closed their offices.

I hope this helps anyone thinking of moving abroad to get “the big picture” and really think about it.

From my own experience, moving to New Zealand has allowed me access to a different jobs market and to experience I simply feel I would not have got back in the UK. But it also was significantly for my son, who I thought would get more opportunities in New Zealand than back home in the UK. For this there have been personal trade-offs, mainly being so far from the rest of our extended family. It's hard at times, having to cope with the death of by close friend Violet whilst half a world away, and likewise my wife had to cope with the death of her father back in Liverpool.

Project Christmas: The Elf Who Learned How To Test

I have had a busy year, no doubt about it, with a lot published in magazines like Testing Planet, Testing Circus and Tea Time With Testers.  There has also been my book, The Software Minefield.

I've recently put together another much shorter book, which is free to download called The Elf Who Learned How To Test, of which I'm particularly proud (great I now sound like Q from James Bond).

The idea started a long time ago with a conversation with Rosie Sherry about the idea of "Imagine there's no testing" back in August.  And that's just what I did with the leap of imagination required.  I imagined Santa's Workshop where no-one tested, and children received substandard presents, and an elf who discovered how testing could add value.

I've been told by others in the testing community I'm a great storyteller.  Indeed in The Software Minefield, I mentioned I'm always telling war stories or parables.  What pleases me about The Elf Who Learned How To Test is that it's a tale not just for testers, but for their children as well.

I think as testers we sometimes are great at joining together as a community and sharing our stories.  But perhaps where we fail is sharing what we do, not just with others who aren't testing, but especially our children.  And my book works as essentially as a Testing Fairytale which can be shared with children, with some thinking activities at the back which I feel the children are likely to score as well in as the adults!

This year has seen me peeling back the mystique around testing for my 14 year old son, who has come in to see what we do.  I keep trying to talk to him about what I do and why I do it.  I try and develop him a sense of analytical thinking, especially in our common area-of-interest which is history.  Unsurprisingly he did well with the activities in the back (which do not have any "right answers", but as more about seeing how you can expand on the story, and how you interpret some things which are not said).

You can download the book here,

https://leanpub.com/TheElfWhoLearnedHowToTest

In addition, I did a video of me reading it for YouTube, but it turned out too big, so I've decided to put it up as a podcast, which can be accessed below,

http://testsheepnz.podbean.com/2012/12/22/the-elf-who-learned-how-to-test/

Podcast Powered By Podbean

This is all aimed at encouraging donations to a very worthwhile charity, Starship, which supports sick New Zealand children and their families.  I have been helping to support this charity through work, and if you'd like to support them as well, please give a one-off-donation below,

https://www.starship.org.nz/foundation/how-i-can-help/making-a-donation-now/