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.
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.
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.
I’m officially out of my self imposed social media hibernation. I tend to creep away from my online presence and catch up with my family over December and January. It’s time to venture out and start interacting again.
I have a load of new and exciting goals planned for this year. I’ve spent the last week doing my planning and plotting for this year, as well as a review of last years goals.
I normally hint at a few of my goals via this blog and on twitter but this time around I’m planning on making my goals more visible. It might make me commit to them further 🙂
So here are a few things I’ll be doing this year that are relevant to those interested in software testing.
Goal 1 – Actually post stuff to my blog
Right now I have 233 blog posts in draft.
Some near completion, some with barely a few lines of ideas.
I suspect some of them will get deleted; they will be either too cutting edge, too ranty or too boring. So I guess I’ll have about 150 to post out on my blog by the time I’ve culled them (and allowing for new ideas to emerge).
There is a theme this year.
The theme will be “hiring testers in to a rapid release development team”. I will explore what it takes to find and hire good testers, but I will also explore some ideas around cutting down the silos between functional roles and creating a more holistic fast paced development team.
Goal 2 – Release “Idle Thoughts On Test Management”
I actually got side tracked writing Remaining Relevant when I should have been writing Idle Thoughts.
I’ve got the basic chapter headings and quite a lot of content, but I won’t be making it public for a few months yet. I will be using LeanPub again to publish this second book. Expect this book to be minimalist and cut down. I want it to be succinct and to the point.
Idle Thoughts is basically a collection of short stories and essays from my time as a Test and Development Manager. Fulfilling many roles through my career (technical author, tester, support engineer, manager, scrum master, agile coach/consultant, etc) has allowed me to blend all of this experience together. I hope to be able to offer some interesting and unique views about test management. Consider it part observation and part experience report.
You can see some of the research content I’m collecting over at my Idle Thoughts Postachio blog. The posts on that blog will arrive in flurries, as will chapters for this book on to LeanPub.
Here are the chapters I’m going to be writing about. I’d be keen to get some feedback as to what else you may want to read about. It’s not complete yet, so expect the following to change somewhat. (Bold and underlined are section headers in the book)
Purpose, Audience and Context – the basics of communication
Communicate 10 x more than you currently do
Time your communication right
Communication doesn’t happen through a process tool
Primary, secondary, or made up information source?
Active listening for test managers
It’s active content, not static documents
Don’t skip face-to-face communication
Private blogging for sharing of ideas
Don’t sit on information, it won’t make the team richer
How to run a good meeting
Broadcast important stuff, but only if you need to
Build a communication plan
DUJWC (don’t use jargon when communicating)
Productivity and Learning
Be Quick and Nimble
Create a practice plan
Follow your intuition
Busy does not mean productive
Where does your day go?
Don’t take on too much
Stop people burning out
Learners will inherit the world
We can’t all do what other people can do
We are all great. But realise your limits.
No job will last forever. Projects are the future.
It’s not good. It’s not bad. It just is.
Lean Testing – A myth
What a lot of tests, but which one shall I run?
Don’t worry about the solution. Work out what the problem is first.
Draw a frame and place your testing inside it (but don’t be bound by it)
Don’t adopt every technique without pause for thought (sometimes just a few techniques are more valuable)
Copy what other people do, where relevant
Don’t master an approach or technique just to say you’ve mastered it.
The team are testing, but is the product getting better?
A difference between intent and outcome
You’ll never know whether a team will work until you put them together
Teams are not perfect.
Look for times when your testing doesn’t work
Do you have a vision and purpose, or are you just getting through the day
Make decisions. Decision makers are important.
With a wider awareness you will be surprised less often
Apply constraints – they breed creativity
Standards versus trial and error
Norms are for breaking. Sometimes.
Allow time for innovation
People will game the system (if they want to)
Leading edge metrics
Improving the process is one of your main goals
Always go and see for yourself. Or trust your proxy.
Test artifacts are an output, not a strategic direction or end goal
A test plan is not your testing. A test case is not your testing. The testing being done is your testing.
Fix the process first – then bring in technology
Don’t obsess over tools
Relationships are your key to success. So be friendly.
Values versus principles
What is the job of a test manager
To hire the right people
To empower people to achieve the business goals
To develop people to their potential
To make decisions
To encourage the right behaviour
To reduce costs in the right place, but not at the expense of delivery
To be communicated through
To encourage a sense of learning in the team
To help people through tough times
The importance of good note taking
Types of notes
Note taking styles
Digital versus Analog
60 Days proof
To Do lists
Visualise your work
Work in progress
Examples of note taking and capture
Managing a test budget
Spend your employers money wisely
Is spending money going to solve your problem?
Lack of money often leads to innovation
Don’t accept limitations
We are too young and we are too early in our careers to standardize us.
Don’t apply limitations to yourself, your team or even worse, the community.
Stop casting yourself as a victim
You are as equally important as anyone else on the team. (i.e. There is nothing wrong with you)
Experience as much as possible
End goals are important, but so to is the serendipity and experience of the journey
Don’t always be laser like focused.
Take the time to look around
Make time for people
Allow conversations to meander
You cannot organise an accident
You will not please everyone
You don’t need permission to do Exploratory Testing
Communities are where the future lies – not rules and edicts
Is it always true? Is there ever a time when it is not true?
Make time for thinking.
Stop trying to measure the person.
Grow some thick skin. Very thick skin.
Goal 3 – Deliver an awesome presentation…somewhere.
As usual I am hoping to speak at a conference this year. Details to follow.
With the above writing plans I won’t be speaking or attending many other events. I am taking the entire NVM test team to TestBash, whoot!, but other than that I doubt I will be at many events this year.
Goal 4 – Continue to build an amazing development team at NVM
I’ve obviously got some great work goals to achieve. I will be continuing to improving the process, grow the team and deliver the best service we can for our customers. I won’t be sharing my work goals here though 🙂
Goal 5 – Start mentoring someone
I’ve been mentoring people on and off for many years, but I might be making a step to make this a permanent goal, so that each year I can help to mentor one person in their career.
I’ve also got some very personal goals which I won’t be airing here either 🙂
Exciting year ahead.
Do you plan goals relating to your career?
If so, did you want to share them in the comments section?
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.
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.
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)
Thisweek I will be shippingmy new blog hosted on ghost.org So that I canstart 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.
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.