As we enter a "next generation" of software testers, guest blogger Dan offers a solution for many-an-employer's biggest problem: how do you hire people with the right skills (now and in the future)?
As someone who meets a lot of testing organisations and practitioners, I get to hear a lot of problems. It’s a bit like being a priest. Over time, you start to notice patterns and one of the challenges that clients frequently talk about is the difficulty in hiring people with the right skills. What does this mean, and how can we overcome the problem? I was very pleased to host one of the topics at 2017’s TestFocus event, and we had some great discussions about this very issue.
What’s the problem?
If the topic under discussion is “next generation testers”, it’s a fairly safe bet that most present will say there is a problem (either real or imagined) with the current generation. The short version of the complaint is that the type of people we have are a poor fit for today’s projects.
Our experience of test teams is that the majority of people fit into one of two camps. More than half of testers seem to come into the career from a business background. They were probably seconded to a project to work on UAT, which might easily have been the only testing that organisation undertook. They discovered that they were good at it (or their bosses did) so they worked on multiple projects. Discovering that they enjoyed testing, they then chose to move into it as a career. Many of these testers focus primarily on business or end user testing. Whilst they may have ISTQB certification, they probably don’t have a technology background or computing degree.
Perhaps a third of the testers we meet in projects come from a technology background, and quite possibly have only worked on software development projects. They might be highly qualified in terms of ISTQB or ISEB, but are quite often hyper-focussed on one aspect of technology.
With older ways of working, this split of skills could be made to work. Waterfall projects split off the more technical testing from the more business process testing, so you can plan resourcing for both separately. In projects which are either less structured (I will avoid the word agile) or where team sizes are pushed down due to the changing economies of development, it is much more important to have a flexible team. Inadvertently, the industry has built a community of testers that are highly polarised in terms of skills and experience, so this is where the problem manifests.
Another inexorable force on testing is the pace of change that people now expect in software delivery. Even ten years ago, most systems had releases annually or even less frequently. Have you noticed how Microsoft Word is now just Word and no longer has the year suffix? It used to have new releases every couple of years. I strongly suspect we won’t see another ‘formal’ update of Word any time soon, just a constant drip feed of updates. This trend has also changed the dynamics of software development, meaning you get new code libraries to test out of sequence or in isolation. You can’t simply focus on the user-facing aspects of a system, and testing code modules without an understanding of context can be a futile activity. Additionally, the need for regression testing grows exponentially with this approach. The old ways of doing things can’t keep up.
What’s the solution?
Clearly there is a need to do things differently, but that requires a different type of test resource. There is a concept that is now quite well established: ‘T-shaped people’. The idea is that team members should have a base capability in all the skills their team needs; being able to write some code, document requirements, define tests and more, depending on the team’s needs. This is represented by the horizontal beam of the ‘T’. The vertical bar represents deep knowledge in one area. So (keeping the example simple) a T-shaped tester would have deep knowledge of testing combined with a working knowledge of coding and business analysis. Most of our typical testers have about half of this capability set. The challenge lies in getting them up to speed, and how we address this depends on whether you are a team manager or not.
From the top
As a team manager, there are a couple of key strategies open to you; one, more long term and the other, more immediate. In the longer term, you can change your recruitment criteria for growing the team. Look for a broader range of skills in your candidates, such as the desire to learn new skills and having an interest in problem solving which are probably good indicators. New tools and languages gain popularity in software development on a very regular basis, so simply having skills is a poor long-term capability. What’s needed is the ability to gain new skills and so have a team that remains relevant.
You need to support this constant learning, and this is where you can help your existing team members, too. Create an atmosphere of continual learning and provide what resources you can to facilitate this. One of our participants worked for a company where everyone got a half day each week for self-development. 10% of all their time! That’s a fantastic commitment by the company, however most teams and organisations will need to work with less. The good thing is that there are lots of worthwhile resources available via the internet and you can build up communities of expertise within your company, sharing experience. Invest in fundamental skills like programming and SQL as well as more specific skills like test automation. Again, flexibility is key to long term success.
What to do with people who really, really don’t want to change? This is not unusual with people in general, and perhaps slightly more common amongst testers as we tend to be naturally cautious as a breed. If you have team members who only want to do manual testing, for example, then consider re-focussing them on exploratory testing as this can be a potentially, very beneficial testing activity and it can’t be done through automation. If people don’t want to learn new technologies or systems, then BAU or maintenance projects might still value that knowledge.
At the sharp end
The onus is on us, the testers, to become more flexible. This is hard! We need to increase our technical skills so that we can write simple pieces of code to drive DLLs or make SOAP requests. We need to increase our analysis and collaboration skills so we can better understand what business value a system needs to deliver.
As a group, we tend to focus on the negative. We’re testers, it’s our job to find problems! That’s great of course, but modern software development needs solutions, too. Make more use of creative solutions in your day job. Develop your skills by building simple tools like SQL queries or recording basic automated tests using a tool like Selenium. Move on to more complex things as your confidence grows.
Experiment and gain an understanding of why we do things. This is a key skill in the modern delivery environment. In highly structured projects of old, you would know what to do because the plan would tell you what you would be doing for the day. You now need to be able to look at the software components in front of you and work out what you can usefully test, and how! This is a high-order skill that takes time and either support or trial and error to achieve. Expect the experience to be a challenge – but it is rewarding when you get it right.
Where will we end up?
For too long, testers have been human drones, just repeating the tests put before them. This enforced drudgery makes our senior stakeholders struggle to see the value of what we do, as we plod along like dinosaurs in their eyes.
As we evolve to thrive in the modern software development world, we will get to do more varied and challenging tasks. We will use our creative skills to solve problems and our experience of past issues to spot them before they impact the team. Our bosses will see our aerobatics as we, like birds, soar over the big picture and then dive into the detail. They, and our peers, will better appreciate the value we are bringing to the team.
It will be a tough journey, but it will be worth it.
