Certifications are creating lazy hiring managers

A certification is not a marker of excellence.

I can say this categorically from the viewpoint of someone hiring testers.

It’s a viewpoint often ignored, dismissed and unheard by those extolling the virtues of the certification as an effective tool for hiring.

I’ve interviewed 100s of testers and I’ve yet to see any direct link between excellent candidates and their possession of a testing certification. Period.

certification of awesomeness
Certification of Awesomeness

To print your own certifications of awesomeness – visit Certification Magic.

Don’t rely on them for your recruitment as they won’t provide you with candidates who have the consistent level of experience, knowledge or aptitude that many people promoting this angle of certifications would have you believe.

If recruiting excellent testers was as simple as pre-filtering candidates based on them possessing a certification, then every software company in the world would have awesome test teams – but this simply isn’t the case.

You cannot presume someone with a certification is a talented tester.

You also cannot presume someone with no certification is a rubbish tester.

Anyone who tells you otherwise is selling you a certification, lying, misinformed or easily mislead in to spouting a message they have not thought critically about.

This doesn’t mean that certifications are bad. They could have their place. In fact I’ve heard some very compelling reasons recently for using the certification schemes. They seem to solve some people’s problems.

But they create problems in recruiting.

Certifications have created lazy recruiters (hiring managers, HR and recruitment agencies) by providing a seemingly easy way to filter applicants. This in turn has given lazy candidates a simple route to getting through the filters.

Candidate no longer need to excel at anything, nor up-skill (other than sitting more certifications) or learn how to sell themselves effectively (Testing Club link to a thread discussing selling yourself) in order to get an interview, and presumably, also land a job.

Overall it’s creating a vacuum of fairly average people all playing certification inflation to keep up with everyone else.

I believe that certifications are not improving our craft in the way many believe they could, or should, and they are negatively affecting the recruitment of testers.

A certification is a business transaction. Lets not pretend it’s anything more. You pay for a course, you get a certificate (and a short amount of coaching/training/lecturing/reading etc).

Certifications are not education and they are no substitute for on-the-job learning, but they may be a useful source of learning and a useful introduction to testing for some.

A certification tells you nothing about the candidate themselves. It tells you nothing about their soft skills, aptitude, motivations, self learning ethos or work ethic. This is important because being a good tester is more about the person than it is about the skills. Most skills can be taught and learned – aptitude, thought patterns and work ethic are much harder to change.

Recruitment is not supposed to be easy. It is hard work finding good testers. Your job as a hiring manager is to find good people. This means your job is going to be hard. Embrace the challenge.

Instead of relying on certifications why not try other innovative ways of getting the right people? It’s not as tricky or expensive as it may first seem. (I’ll be sharing many of these ways over the coming months).

But of course if all you want is another bum on a seat then certifications may be your more efficient way of recruiting.

If however, you want a test team that can help your business adapt to the changes and evolutions it will inevitably go through then you will have to drop your reliance on certifications as a way of recruiting testers; certifications are making both you and the majority of candidates in the testing industry lazy.

Effort on the CV is a good indicator of interest

Picture of a CV Image from The Italian VoiceCurriculum Vitae” March 2, 2008 via Flickr, Creative Commons Attribution.

A general heuristic you could apply when hiring good testers is to assume that the effort on a CV is directly related to how interested the candidate is in working for you.

The more effort applied to tailoring the CV – the more they are someone you want to hire. If you’re looking to hire a great test tester you’ll ideally be looking for people who want to work with you, and not just want any old job.

This is a good heuristic to use, but as always, it is fallible.

Generally speaking though a CV that has been tailored thoughtfully to match your job advert is often the sign of a tester who cares about working for you.

A boiler plate CV with no tailoring is a sure sign of someone who just wants a job – any job.

Be careful though. Not everyone knows how to write good CVs or tailor an application. You may miss some great candidates by applying the heuristic with no other key indicators.

In my opinion though if someone wants to work for you then they will take care and effort over the application.

Care and effort on the application manifests itself in a clean and simple CV with carefully chosen details to support their application. It will contain a sentence or two about each of the aspects in your job advert, even if it’s a simple statement saying “I am currently learning X” or “I am keen to understand more about Y”. It shows they care. And testers that care are the testers you’ll likely want to hire.

In my experience the better the CV – the better the candidate

Your Service Desk is your customer

(In the following post I use the term Service Desk to also mean “support desk” or whatever else you call the people who deal with calls from customers)

Call Centre
Image from Lamont_Cranston “aafad 167/365 call centre-kun” Nov 2, 2008 via Flickr, Creative Commons Attribution. – Image not modified.


Your Service Desk team is your customer.

You may have never thought of them in this way before but they are your customer.

They may not be your only customer but they are your most important customer.

The service desk may not be your company’s most important customer (or even seen as a customer at all to the wider business), but they are most likely your most important customer.

If service desk have a problem, you have a problem. If service desk have no problems the chances are (assuming your service desk is accessible for your end users) you are building and releasing something very good indeed. This is not a problem.

If your service desk are fielding 1000 calls a day about bugs in your product/service then you’re getting something wrong with your development process. And this is your problem.

If your service desk are fielding 100 questions a day about how a feature works then you’ve likely got something wrong with that features suitability, the documentation or the communication around it. And this is your problem.

If your service desk are fielding 10 requests a day and having to do something for your customer that they could realistically do themselves (i.e. resets, unlocking, data configuration) then you’ve likely got something wrong with your product or documentation or communication. And this is your problem.

Your testing (and the Dev cycle it exists within) is there to provide something of value for your end users/customers, whether that be a product or service. And when that product or service doesn’t meet expectations your end users/customers will likely contact service desk. Your customer is now your service desk.

You should do everything within your power to help them support your end users. Your test strategies, approaches and techniques should be designed to support your service desk. Ideally your process will be designed to minimize as many service desk calls as possible, but the reality is you’ll not catch everything. So design your testing to support customer issue resolution.

If service desk have a problem then development has a problem. It’s your job to stop people calling in (by creating something that solves their problems and doesn’t create new ones), but when they do call in it’s also your job to support those on the front line dealing with your end users problems. After all you most likely helped to create their problem in the first place.

Collective Noun for Testers?

The other day I tweeted a picture of our test team testing together as a group (for the first time) in our new test lab.


I asked “What do you call a collection of testers in a test lab?”

Some interesting responses below. Are we heading towards a collective noun for testers? No doubt someone’s done a collective noun post before 🙂


Stephen Newton @SteveAN01 – a play group. Or an informative.

@paul_gerrard – A “Newsroom of testers”

AQtime @aqtimepro – An argument waiting to happen.

George Dinwiddie @gdinwiddie – an exploration?

Darren Hails @rw_testing – correctly located!

mubbashir @mubbashir – Breaking Bad 😉

James Salt @saltpy – happy 🙂

Mark Keats @mkeats – A crash of testers.

neill mccarthy @MccarthyNeill – a curious of…?

Amy Phillips @ItJustBroke – Dangerous

James Lyndsay @workroomprds – an expedition


Thanks to all who responded.

Test Case Completion – A Story

I did a EuroSTAR webinar last week on shipping products and talked about how shipping products using test case metrics is bad news. It reminded me of this story which I share now.

It’s very common for testers and teams to rely on a number of test case metrics and measures to work out when they are done, or to plan the work, or to measure the progress.

This can be very misleading.

A common metric I used to rely on, and see many people rely on often, is the classic “Test Case Completion” metric.

This metric is often used for planning and for measuring completion but more scarily for working out when to release a product or service.

It goes like this

Let’s say we have 10 testers. We also have 1000 test cases. With a bit of magic and maybe past history we can predict that each tester should be completing 10 test cases per day each.

So, that gives us an elapsed time of 10 days to complete all of these test cases. Right?

So now we can plan.

“It’s going to take 10 days to complete our testing”

This happens on almost every single testing project. Test cases and test completion rates are often the guiding factor for schedules and release planning.

We can also use this metric to measure progress.

On day 1 we should have completed 100 test cases. Day 5 we should have done 500 test cases.

If we don’t see these numbers trending in this way (or close to it) then we can adjust. We could *make* people work more hours, maybe achieving 15 test cases per day.

We could add more testers to the mix. Or we could even just not run some test cases.

The Problem

There’s a very obvious problem with this approach. In fact, there are lots of problems yet it doesn’t stop this being the defacto way of planning testing.

One problem is that not all test cases are created equal. Some will take hours to run, some maybe even days and some a few minutes.

Another problem is that there is an assumption that the only testing that needs to be done is contained within the test case.

Another problem is that there is an assumption that testers are like robots who will perform the same each and every day. We all have bad days.

There’s also an assumption that the tester won’t find any problems and hence delay the running of a test case in order to investigate a bug.

A Story

A company once used to run a giant regression phase where all test cases would be run again on the “final” build.

They would print out all 3000+ test cases and stack them on a giant table in the office.

The expectation was that each tester would complete 10 test cases per day – this would allow them to hit the magic release marker of 100% tests run.

Here’s what happened.

At about 5:30am on the day of the regression a group of testers would arrive at the office and rifle through the test cases.

They would pick the really easy ones; the ones that took just a few minutes to run.

They would pick about 50% more than they had to complete.

They did this for two reasons.

Number 1 – they figures that they would be asked to work longer hours to complete more tests – so they already had a stash of easy ones to do whilst eating pizza.

Number 2 – even if they didn’t get asked to stay late they could excel by completing more tests than other people running up to the last few days of the phase.

10 test cases

A second group of testers would come in at 8 am and be left with the really hard test cases. Some of these test cases would require a days worth of setup and config just to run.

Each day the testers would mark how many tests they had done that day on a giant matrix stuck to a wall behind the manager. The first group would mark in the number 10. The second group would be lucky to register 2 or 3.

Some of the first group would surf the web in their spare time, some would help the other testers, some would do exploration, some would go home early.

All of the first group would game the system for a variety of reasons. Yet all of them would be doing what was asked of them according to a simple metric like test case completion.

Not so strangely, the second group of testers would simply not run all of the steps of the test cases (or even mark entire test cases as done without running the checks) in order to try and run 10 per day. When faced with the reality of a 1 day environment build to check one thing….what would you do?

The project shipped late. And it returned to be worked on further.

The scary thing is that this behaviour happens all the time.

When simple measures like Test Case Completion are used to measure progress or to plan projects you’re already skewing the process and opening it up for gaming, abuse and a false start.

What’s the alternative?

I’ve no doubt there are many alternatives to this problem and no system or measure is exempt from being skewed, gamed or misused.

My suggestion would be to move your testing to be nearer the code by pushing for more behaviour driven testing and unit testing which drives out the design, the code and some of the behavioral tests. And then to deliver in to your test environments as soon as possible. If this process works it means you no longer need test cases (or as many of them) as the checking is automated, therefore you don’t need test case completion metrics. Your automated checking becomes a set of results and it frees you up to explore the product and find the things the test cases (or checks) would never have caught….in other words… freeing you up to do testing.

It’s obviously not a simple change (I know I’ve been there) but it is possible and small steps towards these sorts of approaches are entirely possible in almost any context. The real question comes down to how much you’re willing to experiment with testing, reporting and project planning.

No matter what your approach or your context it pays to be aware of the pitfalls of relying on test case completion metrics and to spot the wrong behaviour it drives. At least if you spot it, you may be able to make some changes and encourage the right behaviour by changing your process, or measuring something different.

Michael Bolton blogged about shipping projects and test cases this week also.

You have to believe in change for it to happen

After delivering my talk at EuroSTAR last year about weekly releases I got lots of positive responses, but also some intense negativity and skepticism about the subject.

It wasn’t just “wow – that must be so tricky” it was more along the lines of “you are full of ****” and “what a load of ************ [insert your own expletive]”.

The responses were mostly ones of sheer skepticism combined with aggression. A few people believed it wasn’t possible to release often and that appeared to stir some frustration.

Yet that’s the interesting thing. If you can never picture change happening, or you don’t believe it’s ever possible to move to faster and have more frequent releases then the chances are it wont ever happen.

“It would never work here”

“We could never do that”

“We don’t have the right people”

Three years ago we were releasing yearly and the quality could have done with improving. We could have sat down and looked around and said it’s not possible. But we didn’t.

We believed there was a better way of doing things and we tried.

If you never believe that the development and testing at your company could be better then it simply wont improve.

You (or someone) have to believe things can be different.

It’s my belief that testing standards and best practices are the result of this closed thinking; they assume things don’t change.

The reality is technology is changing all the time, the companies we work for are always changing and the markets we sell in to are always changing.

So couldn’t your approach to development change also? Couldn’t you look for new ways of doing things? Couldn’t you open your mind to a future that different?

The product you test can make or break you as a tester

No product domain is better than any other, but we do each have preferences and favourable products to test. We each prefer to use, test and work with some types of products over others.

When I was testing products I didn’t enjoy I wanted to leave software testing. Period. I wanted out. Software testing sucked.

Sure, the environments/methodology these products were built in didn’t help, but ultimately I didn’t have an affinity to the product and this made me think that the trade of software testing was at fault.

I didn’t understand the product. Actually – let’s be honest, I didn’t *want* to understand it – it held no interest to me. I wasn’t interested. It didn’t make me feel curious about how it worked.

I actually thought I was rubbish because of this.

I realized over time though that it wasn’t me though. I was OK. I was a naturally curious person, just not about some products. It was the product – it wasn’t me.

I’m not curious about things that don’t interest me. However, when I find a product I like and a product I understand I flourish. I become a good tester. I am curious. I am interested. I am engaged. I want the product to succeed. I become a product evangelist. I want to know how it works, why it works and how useful it can be.

I’ve met so many testers over the years that hate testing. Or at least they think they do.

When I ask these testers what their favorite product is they always have an answer. When I ask how they use the product and how the product works they can always answer me. When I ask what it must be like to test a product like this they get wild eyed and passionate about that testing job. And when they notice this enthusiasm in themselves they soon realize that it’s not testing they don’t enjoy – it’s the product that they are testing.

I don’t have an interest in testing transactional banking, insurance products or defense products, some people will thrive testing these. I prefer cloud/hosted/web services that have communication or social interaction at their heart, some people would loathe to work on these products.

So if you’re feeling down about testing and you’re finding you’ve lost your testing mojo it might just be related to the product you’re testing.

It might not be you. It might not be testing. It might just be the way you feel about the product you’re testing.

Shine a light

Most software testing, in my experience, is rushed and often under time pressure, typically driven by a desire to meet a metric or measure of questionable value. Yet to rush through the testing of a feature or product is to often miss the changing nature of that product (or your own changing nature).

If you are testing a capability of a product and look at it in one way (say with the mindset of trying to break it) you may find several issues. If you shine a light on the product in another way (say with the mindset of trying to use the product really quickly) you may spot other issues.

Also, if you test the product on one day you may miss something you may spot on another day. You change (mood, energy, focus) all the time, so expect this to affect your testing.

The product likely hasn’t changed, but the way you see it now has.

Tours, personas and a variety of other test ideas give you a way of re-shining your light. Use these ideas to see the product in different ways, but never forget that it’s often time that is against you. And time is one of the hardest commodities to argue for during your testing phase.

How much time you will need to re-shine your light in different ways will mostly be unknown, but try to avoid being so laser focused on completing a test for coverage sake, or reaching the end goal of X test run per day, that you miss the serendipity that sometimes comes from simply stopping and observing and re-focusing your attention.

Creating a test lab

This week sees the development team moving in to new offices. In these new offices is our newly created test lab. A room for testers to hang out and also a place for us to keep our supported devices.

There’s loads of work to do to get the test lab functioning and adding value for us.

It’s been lead by Raji (Twitter – @peppytester) and Andrew (Twitter – @coyletester)

We’re in a good place with our test environments as they are hosted, just like our great call centre product, in the cloud so we don’t have to store or house our physical servers here in the office test lab.

However, we need to make phone calls and connect via the web hence the test lab – a place to do this, but also a place for the team to get together to do our regular regression testing.

We have the capacity to do our testing with these devices already, but they are localised around individual testers with devices often locked away in a drawer somewhere. Not good for the collaboration and sharing we need to do now as we grow much much bigger. The lab is a way of getting a centralised set of kit, a place to test and a place for us to come together to talk about testing, our test approaches and our supported devices.

Test Lab
Test Lab

Here’s some “starter for ten” goals/requirements we’ve identified for the lab. Obviously the specific details are not listed here but they give you a flavor of what we’re aiming for.

  1. All supported devices and phone carriers must be available in the lab. (i.e. if we support it – we need to test it)
  2. All devices should be charged and ready to use. (i.e. there’s no point needing a device/phone and then having to wait to use it because it’s got a flat battery)
  3. All devices should have a shared folder or other sharing faciltiy on them (Evernote notebook is one example of how we can share screenshots, findings and notes).
  4. The devices must not be plugged in and charging 24/7 unless they are being used. (Although the devices need to be available we don’t want to destroy the planet by charging them all day everyday when they are not being used. We’ll experiment with timers to give them a burst of juice to keep them functioning and tweak it to get a decent balance.)
  5. At busy periods it must be possible to book out devices, but this booking system should be a last resort, and should be a friction free as possible – a casual approach to sharing the devices should be sought first before booking forms and other waste are introduce. (i.e. it takes time to fill out forms, book things and deal with the “paperwork”. What if you just want ten minutes of usage…it’s a massive overhead to book it out. Add this overhead if needed but let’s see how it goes first)
  6. All devices will be connected to the network, clearly labelled (resolution, network, IP address etc) and available in the right place (i.e. people put them back where they come from)
  7. The phones should be included in our generic “default” call plans meaning all testers know where to get extra devices and phones from (i.e. when needed people should be able to easily add these devices to their accounts and gain access to them)
  8. All devices should have quick, one step log in and access (i.e. unless security is compromised let’s make it as frictionless as possible to use these devices and phones)
  9. A monitor showing NewRelic (plus other test related data) should be available in the lab. (i.e. data informed testing and feedback from your testing are key to the right focus)
  10. All default call plans and test accounts should be well documented and easy to follow meaning new starters can rapidly learn how to get on clouds quickly. (i.e. make it quick to get testing in the lab)
  11. There should be a number of network ports and power sockets available to house groups of testers doing testing. (i.e. when a group of testers (what’s the collective term for that???) get together is there enough power and cabling?)
  12. All test related books should be relocated to the test lab (i.e. when we need inspiration it should be there)
  13. Elisabeth Hendrickson’s cheat sheet will be available – ideally blown up and made to look freaking awesome. (i.e. ideas for testing should look good as well as be functional)
  14. The test lab should remain looking neat, tidy and welcoming (i.e. clean, simple, tidy and functional environments help to clear the mind for focus on productive stuff)

And there we have it. A starter for ten. But something to head towards.

I’ll keep you posted, as I’m sure Raji and Andrew will on Twitter about how we get on.

What do you all have in your test labs?

You’re brand new

“I’m new to testing – where do I start?”

I get asked the above questions A LOT. It’s a very common question for those who are brand new to testing, those who are shifting from another business function and those who are returning to testing after many years away.

I repeat roughly the same answers quite often so I’m writing a blog post to point people at.

Of course, a little self promotion – if you do nothing else then buy my own remaining relevant book – it is packed with ideas on how to learn, how to network and hints and tips on how to rock an interview 🙂 You could consider it a much longer form version of this blog post.

Join the Software Testing Club. Period.

Check out the AST training courses and learn as much as possible.

Follow the big bad list of test bloggers being curated by the Software Testing Club – there are a lot of them – mostly good – pick and choose carefully though.

Download and read my Blazingly Simple Guide To Web Testing – all of the hints and tips were created from bugs I’ve found in the past.

Join twitter and follow the #softwaretesting #testing hashtags – find interesting people and follow them.

As part of the above question I also often get asked what the day to day activities of a tester are.

It’s tricky to say what the day to day activities of a tester commonly are as the role is so incredibly varied. You might be following pre-defined scripts and checking that the software matches the test case.

You might be exploring the product to discover what it does. You might be analyzing specs, writing user stories, writing automated tests, performance testing, security testing, doing customer visits, studying usability and a whole host of other stuff. You might do some of these things during one working week at some companies, you might do nothing but following scripts at others.

The industry is so varied that I would suggest, if you can, that you take the time to carefully chose the testing role you want. I would always suggest seeking out companies that put exploration and learning above scripted testing, but not everyone has the luxury of holding out for such companies.

Some companies will insist on a certification. It’s your choice as to whether you want to get one. I’m not a fan – but I’m a realist – some companies require them – and if you need a job then go for it. But take the certification for what it is – a certification that you sat the course and got a favorable result. It is NOT a marker of excellence and shouldn’t be your single point of learning.

If you follow some of the above you’ll encounter people and communities that will help you find the resources you need, the people you need to know and hopefully the sources that can help you skill up in the right way. You might even land a job through your networks and community.

Getting Hired – At Conferences

One of the things that I have observed from a number of testing conferences is that none of them have any sustained focus on hiring or getting hired *.

There have been one or two sessions about the topic of hiring but nothing sustained.

The occasional tracks that I have seen have been mostly focused around the hiring strategies of big corporates where bums on seats is sometimes more important than cultural team fit.

Most testers don’t know how to get hired – I wrote a book to help bridge that gap. Those that do know how to get hired are truly in the minority and appear, at least on the surface, to be overall better testers. Mostly this is not true – they are good, but they are often no better at testing than others, it’s just they are much better at getting hired. Getting hired is a skill.

Hiring and getting hired is a vast topic and one which is fraught with contextual challenges, but I believe that a dedicated set of talks from hiring managers from a wide variety of contexts, and maybe some sessions and tutorials on writing CVs, interviewing etc would go down well at most testing conferences. It’s great being good at testing but how do you then go on and get hired…

There are supporting topics such as social profiles, writing clear CVs, networking, self education and interpersonal communication that might also make interesting tracks. Or maybe they wouldn’t. Maybe people go to testing conferences to learn about testing and not the other stuff that comes with our working world…

What are your thoughts?

* The conferences that I have been to

Our community is not best served by one single group

Our community is not best served by one single group or organization. [Opinion piece follows 🙂 ]

As an individual it’s important to be skeptical when we have just one single source of learning and direction for our community. If we tie ourselves to a single source (i.e. group, organization, business, scheme) we are tying ourselves to a narrow (and potentially narrowing) point of view.

If we do narrow our focus to a single source we will hinder our knowledge growth and our learning scope. I believe there is another side effect though – the wider community will become more fragmented and distant as we become less tolerant of alternative views…(I have no evidence for this, just observations)

Groups that were once a mouthpiece and meeting ground for the unheard and diverse minorities soon narrow as they find a niche, or attract a tipping point of like minded people – this is natural which is why there is always room for new groups and communities to emerge to fill the gaps.

As groups narrow they will focus on specific areas. Some of these groups will inevitably try to make money by selling services (or information) to survive, some will just tumble along whilst others will seek external funding. Some will disappear. Some that do disappear will leave a gap to be filled, some will not be missed.

We need to be sure to keep our mind open and notice when we start to become focused too narrowly on our learning and our community involvement. It’s not heresy to switch communities or to exist across several seemingly different communities. In fact, I would positively encourage mixing views and opinions together. Our interests and persona’s are elastic, we must try not to resist this.

Look at the standardization schemes. In order to scale (i.e. to make money – assuming you believe this is the primary goal of those behind them) the content must to be filtered down, made consistent and change as infrequently as possible (what a bind it would be to re-print the marketing and other collateral every week to keep up with industry innovation).

In order to embark on such a dramatic process those behind it will seek to own the learning material contained within. They may want to protect it. They may want to ensure they are the only ones offering it. They may tell you that you cannot get this learning elsewhere. (note: some communities do this also)

They are wrong. Some, if not all, of the information is available freely (or at least cheaply) to us, on any device or platform we care to consume it from. Not only that but it may be opinionated (in a good and/or bad way), will naturally be diverse (if we look far enough for it) and is hopefully being shared by people actually doing the work. It will therefore change often. This is good.

And as it’s freely available we could, and probably should, mash it around, mix it up, fine tune it, fix it, extend it, delete it, try it, ignore it and make of it what we need it to be. This will be where the giant leaps in our thinking about testing will come from. From us; the testing community mashing together ideas to see what works, and what doesn’t.

And once we’ve made of it what we want then we could share it so that others can do the same. This will lead us to an evolution (or a revolution) in the way we approach testing.

Instead of small incremental improvements on the standards/norms we might see a major sea change and a dramatic shifting of our craft – I look forward to this day.

I believe the testing community needs more people to seek out diversity in our sources of learning and inspiration.

I also believe we could challenge anyone and anything that suggests a single source of information and direction is the right thing for us. We could seek out the free and open source learning that is available to us. We could challenge the old guard and stale approaches to learning (and teaching) of software testing.

We could create a community of interest if one does not exist. We could seek clarity as to whether someone is protecting a mass of knowledge for the right reasons (and no-one should begrudge anyone making a living from selling what they know) or whether it is to seek conformity and standards of the masses.

But most of all we should try hard not to let ourselves sink in to the sea of conformity and oblivion that is consuming so many people where we simply become a nodding and compliant member of a single source of direction for our community. I know we can do better. Our craft is evolving and we need more people to help gain momentum to nudge it to a diverse future rather than single path of conformity. We can do that.

Shipping Forecast – A Way To Get Things Done

I was chatting to someone at EuroSTAR last week and we got talking about personal productivity.

I shared with her my way of working using a concept I’ve been calling Shipping Forecasts. It’s based around the simple premise that I will be shipping something (a project). It is called a forecast because no amount of planning is a guarantee, so I am forecasting about what is involved in shipping this project.

My view is that projects are simply containers for tasks, and completing the tasks is what’s most important. But these tasks should be viewed in the context of what I’m trying to achieve – i.e. why am I doing this project?

Anything worth shipping will take a significant amount of effort and will need some form of forecasting.

This forecasting could be a quick scribble in a notebook or a full on project plan – a lot depends on your own style and own way of working. I like to visualise my work and list out what I believe needs to be done to complete the project.

By breaking a bigger project in to smaller chunks we can start to see what is truly involved. I also believe that any project that will take more than about 1 month should be broken down in to multiple projects. Each one of those projects should be shippable and feedback should be sought before moving on to the next project.

In a sense it’s the basics of iterative software development.

I thought I would share with you my Shipping Forecast idea that I use to break down my own projects in to manageable chunks.

Since I’ve started using this technique I’ve been uber productive.

There are times when I get a little lost or don’t feel like producing anything but rarely does a project sink because I didn’t understand it, or couldn’t actually complete it, or didn’t know what was involved in completing it.

A few people have been using the Shipping Forecast for some time now so they have been through a few reviews but there is always room for improvement – don’t expect the templates and the idea to be complete – I’m still hacking it.

An example of the Shipping Forecast
An example of the Shipping Forecast


How to use the Shipping Forecast templates

To start with you’ll need to define a project in the format of

This……(date, time period, month, year, etc) I will be shipping…….. (the end product) So that I can…………….(the reason why you are shipping it)

For example:

This week I will be shipping my new blog hosted on ghost.org So that I can start blogging about my addiction to stationary

If you cannot fill in these sentences then you need to question why you are doing the project.

The project must have a deadline otherwise it will meander on and on. Don’t fall in to the trap of relying on your own enthusiasm and energy. Most projects require hard work and tiresome commitment – a deadline will help. You don’t always have to specify an exact date, but the information you fill in should mean something to you. For example: “This Week” is fine if you know that your weeks finish on Saturday for example.

You should be able to describe what it is you are building at a high level. You must know how to recognise the end result. Is it a product? A website? A new blog post? A new t-shirt design? A new test automation tool? You must also think about how complete you need it to be. Are you shipping the finished item, or just phase/design 1 of it?

Your project should also have a reason why you are doing it. I’ve seen too many project stumble because the project owners didn’t know why they were doing it. Don’t do something because you think you should. Do something because you need to or want to. Why are you bothering to commit to this project?

There are some prompts below the description on the template to help you think about how you will measure your progress, how you will know you are done and whether you are reliant on others. Projects can fail because they rely on other people and these other people didn’t know that.

There is an action section with 20 spaces. If your project takes more than 20 tangible actions that can be marked as complete, then it may be that your project is too large or you have broken the activity down too much.

Some people use this form to work out the 20 activities they need to complete and then break those 20 items down further in another tool, like a To Do list manager. This could work really well but I’ve found that any more than 20 deliverable items to achieve Shipping is just too much. I find it’s better to have more projects and ship each one than try to do too much.

And that’s it. The Shipping Forecast – a tool for helping you work out what you need to do to ship stuff.

Some examples

Here are some examples of Shipping Forecasts that I have done.

Our Garden Project


An example company launch


Updating your CV


My own publishing of the Shipping Forecast template



Here is the PNG (image) of the Shipping Forecast for you to download. I’m working on getting a better quality one created.

Reliance On Colour

One of my major bug bears is the reliance on colour to communicate meaning. As a tester it’s super easy to question any product or communication that relies on colour. Just ask whether meaning will be lost if viewed without colour.

If you have a graph for example where each line is representing a finding or value, and they are each different colours then print the graph in greyscale and see if you can still make sense of the data. Is the key good enough, are the lines slightly different shapes (dot, dashes etc) or do you lose all functional understanding?

Relying on colour to communicate meaning is often a very lazy approach to designing products and it’s something we, as testers, should be acutely aware of and test for.

It’s never right or wrong to use colour to communicate meaning but we should always ask the question; “Will we ever have a circumstance where someone will not see the colour as we have defined it and hence lose the meaning?” Or some other better phrased question.

Here’s a good tool for putting yourself in the shoes of someone with varying magnitudes of colour blindness – http://colororacle.org/

My site under “Normal Vision”

The Social Tester Site - Normal Vision
The Social Tester Site – Normal Vision


My site under “Deuteranopia” vision – it’s a green deficiency and affects about 5% of males

The Social Tester Site - Deuteranopia Vision
The Social Tester Site – Deuteranopia Vision


My site under “Protanopia” vision – this is quite rare.

The Social Tester Site - Protanopia Vision
The Social Tester Site – Protanopia Vision


My site under “Tritanopia” vision – this is very rare.

The Social Tester Site - Tritanopia Vision
The Social Tester Site – Tritanopia Vision


My web site doesn’t rely on any colour to conduct meaning but you could quite easily see how some websites, graphics and explanations could clearly lose their value when viewed by someone with colour blindness.



Career Paths And Testing

When you’re advancing your career in testing it’s easy to get sucked in to the lure of big titles like Test Manager, Programmer Manager etc, especially if your using some of the mainstream “career path” guidance tools. The offer of a test manager role might seem like an attractive offer compared to a “test engineer” or something like that. However, apply caution, in my experience most test managers I’ve known have done little other than manage artifacts (test cases). A role title does not accurately reflect the role.

Use your own judgment when you’re applying for roles with big titles. Someone I know is a Test Manager….of himself (and some test cases).

I know a Director of Test who manages a team of 2 testers (and lots of regression test cases).

I know someone who works for a test manager. This test manager manages a team of 45 testers doing nothing but regression testing. The team keeps growing but the testing is not changing. By all accounts he’s hiring people and getting them to manage a load of test cases. Is this test management – I guess so.

After fulfilling your basic needs like salary, location and any other contextual needs I’d suggest to try to find a job that challenges you, not a job that gives you a so called “career path” title.

Find a job that challenges everything you thought you knew about testing. Find a job that provides you with an environment you’ll thrive in. Try to find a job that is modern and relevant. Try to find a job that let’s you think…and gives you room to breathe.

Try to find a job that blows your socks off. And don’t worry too much about what you’ll be called.

Oh yeah – Did I mention I was hiring for a solid tester who likes a monumental challenge?

Oh yeah – I also write a book called Remaining Relevant about how to find those great jobs, get the skills you need and then rock an interview. You can buy it here on LeanPub