What if you don’t have the skills a manager is looking for?

What do you do when hiring managers are looking for a set of skills you don’t have but you sorely want? You learn.

I see this situation played over and over again. The market is shifting and a new tool or technique is the next biggest standout skill or experience hiring managers are looking for, yet you don’t have that skill. What’s worse is that you can’t get an opportunity to learn that skill in a workplace because you don’t already have it…..a Catch 22 situation.

Read More

Why testers really should learn to code

Testers need to learn to code *. Period.

And here’s why.

The market demands it and the supply is arriving.

As a hiring manager I’ve personally seen a massive increase in the number of testers who can now code. They may not be able to write production grade feature code, or automated tests, but they can write scripts to help them test, or they can write a small app that will inject data or they can extend an Open Source tool to make it work for their needs.

They can basically dig deeper than what you see on the screen, do more with automation and do a more varied set of testing by using tools and code. I see this as a positive thing – I know some people may not.

There is also a growing number of developers who are moving in to a technical testing capacity and learning how to do good exploratory testing and test planning. The market is buoyant for testers who code (and who know how to sell themselves) and it’s good for hiring managers. It’s quite rare now for me to find a tester who isn’t coding, or at least really focused on learning it.

In a nutshell the market is now being supplied with these once elusive testers who can code.

You could of course replace “learn to code” with “learn to do security testing” or “learn to do performance testing” but the reality is that most of these niches also require coding or scripting experience. It’s rare to find a tool that pops out of a box and does what you want it to do – despite what many of the tool vendors sales people will tell you.

To ignore the shift in the market is to leave yourself at a disadvantage when trying to get a job.

Whether you believe that coding is essential to being a good tester or not will soon become an irrelevant moral viewpoint. Testers now need to remain relevant to those with jobs, and those people with jobs for offer are starting to get multi-skilled testers (or T-Shaped as I call them) applying.

Instead of investing energy in fighting the inevitable train of change it might be worth spending that time learning to script, or carving out a niche in another aspect of testing (security, usability, off-shoring, test management etc), or resigning yourself to being outpaced in job applications.

We should be careful though to discern from simply following trends such as certifications and following evolutions in how testing is done. One is very dangerous and leads to lazy recruiting and competitions like certification inflation – the other is a natural progression of our testing craft. Learning to code is deeper than a certification; it’s a skill that can open up many new doors and give you access to tests that were once impossible without some code. Of course you could rely on the developers in the team to help out and that models works well, but the market is shifting and to remain relevant in this market means your skills will need to shift also **.

It’s no longer enough to be a tester who doesn’t code, because when you apply for a job you may be up against a tester similar to you who can code ***.


* Note – there are of course many roles within testing that mean coding or scripting is not essential such as management, strategy, coaching, leadership/directorship roles and problems solvers etc but for the mainstream testing roles the times are changing.

** Note – shifting skills could also mean learning specific tools, learning how to solve problems or, as the post suggests, learning how to code.

*** Note – of course – there are also lots of other ways to get hired rather than applying for a job – thought leadership and networking are two – I cover lots more in my book.

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.

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.