Elvis, Project Frankenstein and the Linux experience ...

Warning - this entry contains naked computers ...

There is no feeling quite like bringing home a brand new computer, and getting it plugged in and working for the first time.  Over the years I've noticed that "settting up a new machine" has gone from being about a day's work of driver installation and fiddling around to under an hour's effort to "set up the essentials".

And that old machine of yours?  Well that's dated and of no use to anyone now ...

Actually, hold that thought.  Unlike the 80s where we started out with home computers with 1KB memory running on tape, and finished with 1MB memory machines running on diskette, in recent years although computers are getting smaller and more powerful, it's not been anywhere near the dramatic shift in performance.  There is still life in your old dog yet.

Windows it has to be said is an amazing piece of software, and later versions have got better and better.  The reason it's so amazing is that the range of hardware it can cope (pretty well) with is vast - just about any form of PC, with different memory units, hard disks, processors, games cards etc.  I know Apple at the moment has a far superior reputation - but remember that with Apple iOS, Apple owns the hardware and the software - meaning the software has to run on much less variety of hardware.  So kudos to Windows, it does a pretty good job on an ocean of hardware, a Herculean feat in itself.

But because of this, Windows can sometimes become quite bloated, and after a couple of years of updates, your system is starting to feel like Elvis playing at Las Vegas, some of it's sparkle seems to have gone ...

This is usually the point you start shopping for something new, in the years since you bought your computer Elvis, the hardware has got faster and a little leaner, so though you're "All Shook Up", you buy yourself a new machine.

With that new computer smell firmly installed as your "Latest Flame", with your email, Facebook and internet needs addressed, is it time for Elvis to leave the building?  It may feel like it "Ain't Nothing But A Hound Dog", but "Don't Be Cruel", there is indeed still life in this canine yet ...

If you have no technical skill what-so-ever, and plan on doing nothing more to this machine, consider just this ... normally when you have a computer, you use it under the watchwords of "Love Me Tender".  Your computer contains your contact details, social networking, photos - you need to take care of it.  But a spare computer ... if that goes down, does it really matter?  No, because you have a backup.

All of a sudden you have a machine which is much more about trying things out, going "I Wonder" what happens if.  Trying things out, because if you send it to a permanent blue screen of death "I was only going to throw it out eventually anyway".  Our computers at home we need to take care of, but the best experimental testing comes from trying things out.  But at home, few of us have the technical skill to keep it restored.

Feeling more adventurous?  I hoped you were ...

Beyond just using your machine as simply an experimental computer, you can look into reviving it as a Linux machine.  Linux overall is a lot more lightweight than Windows, being based on a Unix operating system (much like iOS).

Back in 2005 I bought a replacement computer in a scenario similar to the above, and found myself left with an old PC.  A developer friend of mine, Michael McConnell (author of the dubiously titled MailStripper application), suggested I use my old machine to play around with Linux.  Michael was a passionate evangelist for Linux, and provided me with the RedHat disks I needed to get started.

Post-installation, I was seriously impressed with the speed the machine worked at, although even as a Unix engineer I found the command line fiddly at times.  Since then, I haven't been without a Linux machine in the house.

Todays modern Linux is fully GUI driven, and my son uses a version of it without needing the command line (he doesn't know Unix commands ... yet).  It's developed by programmers in their spare time as a world project, and many variants are free to download.

And when it works, it works beautifully.  On Vista, when I tried to open some videos from my camera a few years ago, I got an error message that the video file was not supported.  So many hours on Google later trying to download Codecs, I finally got it working (I'd also in the meantime downloaded a lot of crap).  The same situation on Ubuntu of the time, I double clicked the video file, and it said "you do not have the codec file to run this".  But then connected to the internet, and analysed the file, suggesting the codec I would need, and asking my permission to download it - a whole other user experience yes?

My friend Violet was a passionate advocate for Ubuntu.  Until recently this was the Rolls Royce of Linux, however I've found the latest version has felt a bit slow (on my circa 2003 machine).  This variant runs on my son's netbook machine after I accidentally compressed the main drive on his XP computer and couldn't restore it (Ubuntu to the rescue), and he loves using the Unity command system - the icon bar to the left of screen,

Fedora I've had on an old machine for a while.  It's a good, solid product, but nothing to get too excited about.  It's a bit like owning a reliable, low-maintenance Shire Horse over a highly-strung racing stallion,

I've recently built a Mint machine after hearing the raves about it.  Raves which are truly justified.  It's a beautiful operating system, that feels very sleek and quick, and easy-to-use.  The "leader" in the Linux race is constantly shifting, but at the moment it looks to be Mint,

Samba!

Linux machines can be used to run Samba, which is a file sharing program - meaning you can use your central machine in your home network

Get involved?

Remember, Linux is a free product, and as well as programmers, it also needs testers.  The various variants of Linux depend on people cataloging the defects they encounter, and there are wide communities out there around the product looking for contribution.

I suggest to people new to testing, download a Linux system, and get trying.  Plug into the communities, build networks, and get used to finding bugs, but also reporting them.  I suggest exactly the same to more experienced testers who want to try their hand to expand their skills.

On Ubuntu, I helped my son write his first ever bug report - yes it was a proud moment!

Goodbye Project Frankenstein

I mentioned my "Frankenstein machine" back in Welcome To The Testing Mancave.  Originally I had an old computers power supply burn out, so bought a cheap old machine from TradeMe (New Zealand's eBay) as a replacement.  What ended up happening is I "combined parts" to machine a new machine from the two - mainly by trial and error in seeing what would work, and what wouldn't.

Good hint here, but it takes aaaages.  Start from a machine that works, then change one piece of hardware at a time, booting it up each time.  That way if for instance you have two memory cards which can't stand being in the same machine, you'll work it out.

Anyway, the machine was originally designed to be for my son for his secondary school work - just enough to internet search and do word processing.  In the end I so enjoyed fiddling with it, it became my main computer, and he eventually inherited my old netbook instead.  Amongst it's many uses, I run the file sharing system called Samba on it, which means we have a central depository of films, photos, documents in the house.  Useful as even my wife's iPad can browse through the photos in here (handy as she has only the 16GB model, and she loves photos).

But mainly it's been used for writing - most of this blog and indeed the Software Minefield was written on this machine.

Unfortunately lately it's not been performing so well on Ubuntu, and lacks the fancy graphics card that would make it work optimally.  So I took the somewhat heart-wrenching decision to merge 3 of my Linux boxes down to just 2 (with better all around spec), and Frankie (as I call her) is being decommissioned.

However true to the tale of "Frankenstein", this is not the end, as parts of her are going into another machine (nicknamed Zen from Blake's 7), which is now running my version of Mint, and benefiting from Frankie's hard disk, memory and interface card, whilst giving an extra experience through the graphics card, the slightly faster processor (2.4 GHz) and increased memory from the original Zen (3GB memory all up from 1.5 GB - not bad for an 8 year old PC).

Zen - my new main computer.

But yes, Frankie has been a good friend ... but I can't wait to see what I'll learn through Zen.

Farewell Mike Powell - a gentleman and a scholar ...

This weekend I sadly learned of the death of a friend of mine from University.

Back in 1994, both me and Mike Powell were technically "mature students" at the University Of Essex.  I was 24 and studying for a Masters degree in laser physics, he was in his 40s and studying a philosophy degree.

Our paths crossed through a campus drama group we both became involved in - "A Flash Of Inspiration Productions".  The group, far more than any I've been involved with before or since, really aimed to bring out acting ability within people - yes even physicists!  We would rehearse for a play under producer Abigail Cheverst, but she would lead us in workshops to do so much more.

Being in "A Flash Of Inspiration" was not about sticking to the script and learning your lines.  Workshops would have you acting out "like your character" in different improvised scenes to really get under the skin of who your character was.  One of the activities I remember the best was where we'd have to act through a scene, and a couple of fellow actors were given deliberate instructions to attempt to ruin it.  With a couple of people forgetting lines or giving the wrong lines, it was up to you to improvise your way back towards the story "without making it look like anything was wrong".  It's probably this training which means as a tester I'm quite comfortable to use the scripts we might have as guidelines and "explore off script when needed", but more importantly look for the pieces of the script which matter and have to be there and the stuff that's just "fluff".

At 6' 2", I'm a pretty big guy, but I was dwarfed by Mike Powell, who we all called "Big Mike".  He was a clever person, and quite a character - part revolutionary, part hippie - who seemed to know rather too much about political history, and was an influential figure in the campus Fifth Monarchist "Anarchist Society".

But most of all I remember through "A Flash Of Inspiration" his amazing ability at improvisational comedy.  Two such sketches really stand out,

• "Smile For The Judges" was a sketch where a ballroom dancing couple's relationship is crumbling during a dance competition, as each reveals what they know about the other's infidelities.  Their exchanges become ever more bitter about how their marriage has fallen apart, punctuated ever so often with Mike reminding his partner to "smile for the judges" to pretend everything on the outside is a garden of Eden.
• In "We're Down To Our Last Geologist" an expedition into an unnamed wilderness has gone badly wrong.  The last two survivors challenge each other over the deaths of the rest of the party, as it becomes increasingly obvious the two have been turning to cannibalism to survive.

In recent years, I'd reconnected with Mike via Facebook - he still lived in Colchester around some of our friends from University, whilst I'd spread my wings.  It was good to connect up with him - still as passionate and influential as ever (voles had been a big interest of late).  Although I knew he was battling a tumour, you always hope for the best.  However I learned this weekend that he died a couple of months ago.

Like Violet, Mike is worthy of mention on this blog despite being nothing to do with testing, because he is someone who Mark Steel would identify as "a person with a passion".  Mike through political activism and storytelling was an incredibly passionate person who talked about ideas and ideals, unafraid to compromise.  And yet someone you could disagree with, and still be friends.

We need to grow up around that sort of environment so that we can learn to find our voice as well to speak when we need to over the things that matter.  And as Mike showed us young things to speak intelligently, draw people into your ideas without ranting, and sell it to them.

RIP Mike Powell ...

Testing with personas ...

Last year whilst i was still at Kiwibank, I was lucky to attend a morning lecture by local company Optimal Usability on "Putting personas to work".

Many people who've worked with me will know I am not a morning person.  However I was glad to make this early morning event, mainly as within Kiwibank I got to network with a whole load of people I'd normally not have a huge amount to do with - Market Managers, Customer Experience etc.

A persona is mainly used for marketing - they are supposed to be a core of about 4-6 characters (who often have a bit of stereotype about them) who represent a cross section.  We had several at Kiwibank, and when we'd look at changing or offering a new service we'd look to see which of those personas would want in, and which might want to go elsewhere.

For both marketing and testing it's a powerful tool - it's where testing steps into the realm of method acting, and you try to see an application through another persons eyes.  This touches an important feature - your software might well functionally do everything that it's supposed to - but is it going to be something that people are going to feel comfortable using?

Personas should be a one-pager, of something people can instantly connect to, because everyone has met a "Pam" or "Tony" or "Chris" in their life (hence why here a bit of stereotype is handy is it's shortcut language).

Personas can be made from detailed market research to tie into a targeted customer base.  Whilst reading Elisabeth Hendrickson Explore It! she mentions personas as a tool for exploratory testing.

Whilst talking to Lisa Crispin about "software culture" recently she mentioned about how many of her team enjoy roleplaying.  In fact "exploratory testing with personas" is very much like role-play testing.  I couldn't resist trying to draw up some character sheets (I'm an ex-roleplayer, so don't act so surprised).

I wanted to imagine I had some form of "software management tool" (which we've all encountered at some point).  Maybe it was HP's Quality Centre.  Perhaps something like Pivotal Tracker.  Or New Zealands home grown Enterprise Tester.

I was going to work from scratch (although I have zero market research budget), then remembered it might be fun to revisit the people I call "the world's worst Agile Team" from An Agile Murder Mystery.   Maybe this group wasn't an idealised group for "understanding your market", but from a testing perspective they would allow you to thrash your software in ways you'd never before imagined ...

Mrs Peacock – Business Owner 

“I just want to know what the current status is” 

Personal Computer 
Mrs Peacock uses a Windows 7 laptop.  She’s out of the office a lot, and uses a variety of wi-fi points (some slow) to login.

Browser 
Internet Explorer 8

Usage rights 
View ability only

Tool habits
Mrs Peacock is mainly interested in seeing the big picture of the project, and wants to be able to see clearly how things are going, and it be able to take her into any issues.  She wants to see how things have changed.
She uses her laptop a lot on slow connection.  She also depends on the trackpad (she doesn’t carry a mouse with her), so she relies a lot of shortcut keys and wants any icons to be easily clickable.

Colonel Mustard – Project Manager 

“I need to be able to assign work items”

Personal Computer 
Mustard has been upgraded to a new Windows 8 laptop, and has been known to take an iPad into meetings to check updates.

Browser 
Internet Explorer 10

Usage rights 
Create work items and assign tasks

Tool habits 
Mustard is keen on being able to set work tasks to his team, see what they’re working on/progressing.  He sets pieces for all the team, but never himself works on end-to-end individual pieces.

He likes to be able to perform the same actions on multiple elements over having to keep repeating the same action.

Reverand Green - Architect 

“I wonder what happens if …” 

Personal Computer 
Green has made a big noise about being allowed to have a Macbook Pro, even though most of the company is on variants of Windows.

Browser 
Safari

Usage rights 
Full Administration Rights

Tool habits 
Green often plays around with any new features, and will often try and come up with new ways to do things.
Forever optimising the work-flow.  Often this means changing the flow for which there is currently data in “the old system”, and hits migration issues.

Miss Scarlett – Business Analyst 

“What’s next?”

Personal Computer 
On a desktop running Vista.  Don’t ask her how she feels about that, as she feels she’s due an upgrade.

Browser 
Opera

Usage rights 
Basic user – rights only over tasks assigned to her

Tool habits 
Scarlett doesn’t look at the big picture tool, just goes straight into and views the tasks assigned to her.  If work items aren’t assigned to her, she won’t go looking for work.

Prof Plum – Programmer 

“I don’t have time for this …”

Personal Computer 
Difficult to say – he has a cluster of a lot beneath his desk, running different flavours of Linux, and connect to a bigger Samba server that no-one is quite sure of the location of.  Certainly there are so many monitors on his screen, the company made major savings getting him to turn them off over Christmas … 

Browser 
Firefox … with so many plugins you don’t want to know.

Usage rights 
Basic user – rights only over tasks assigned to him

Tool habits 
Prof Plum finds spending time updating his tasks an annoying diversion.  He dislikes intently being asked after changing something “do you really want to do this? OK / Cancel”.  He’d much rather it just does it, and there’s an undo button if he changes his mind.

When it comes to filling out any form, he’ll always do it with the minimum mandatory fields possible.

Mrs White - Tester 

“I don’t see what was wrong with the old way of doing things?”

Personal Computer 
Two years ago Mrs White was upgraded to a Windows Vista desktop, which had issues during updates.  She didn’t like it, and rescued her old XP machine, which IT is now struggling to find parts to keep going.
Because her eyesight isn’t the best, she runs the machine on low resolution so it’s easier for her to see the icons (people have tried to tell her there are better ways to do this, but she’s sticking to it).

Browser 
Internet Explorer 7

Usage rights
Basic user – rights only over tasks assigned to her

Tool habits 
Mrs White spends a lot of time getting things right before submitting (unlike Prof Plum, she tends to fill in EVERYTHING).  Sometimes this means things get timed out.  It’s important to her that she doesn’t lose her work.

She’s also a creature of habit.  She knows a lot about the business area, but she really struggles with anything new.  She will make a lot of noise if changes mean she can no longer do something she used to be able to do.  She doesn’t like naming conventions or icons to change.

A source of testing inspiration?

Reading through that you probably have an idea of a few basic tests you'd like to run - cross browsers and computers for start.

But for Mrs Peacock you want to be able to login and quickly see "the big picture" and drill down.  Whilst Miss Scarlett wants to just be able to quickly see what's been assigned to her.  Can the system do both well without compromise?  Can this release cover Rev Greens desire to experiment vs Mrs Whites need for familiarity?

I found in writing these people out, I obviously went back to my source article on the Agile Murder Mystery.  But the key thing for "filling them out" was to find a picture of someone I felt "had the qualities".  Once I could see "who this person was like", a lot of the other details fell into place.  You will also notice in my choice of photos, I'm also a sci-fi geek (like you didn't know already).

If you want to find out more about personas - how to make them etc, the original presentation slides are still up here,

http://www.slideshare.net/slideshow/embed_code/14323974?hostedIn=slideshare&page=upload

And Optimal Usability do all kinds of blogs, articles and even a newsletter about areas of usability, including personas.

You may not have a market research budget - in which case, just do what I've done, guess, then put in front of a business owner or marketeer and see what feedback they give ... go broad in your guesswork, and put some things which are deliberately provocative in there ...

• "do we care about XP users?"
• "what about all these browsers?  Are we just going to go with IE?  Why shouldn't we just go with IE?"
• "why would someone want to access from an iPad browser?"
• "should this be accessed outside an organisations server from public wi-fi?  Should it be in the cloud?  Do we have strong enough security?"
• "companies don't work much on Linux do they?"

Have fun!

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!