Quantcast
Viewing all articles
Browse latest Browse all 3

Testing: An Obvious Career Choice

Image may be NSFW.
Clik here to view.
test engineer skills map photo
Back in June, I read with much interest the article by  John Stevenson which discussed career progression for testers. This really struck a chord at the time (and still does) because we have just started wrestling with this issue in my current company.

Following some worries around employee engagement, myself (head of test engineering) and the rest of the functional head team (software engineering, project management, technical authoring, user experience) set about talking to each and every one of the people within our respective functions. We devised a set of (somewhat blunt!) questions aimed at getting a true picture of their current view on their career, and their role at the company.

Firstly it was great to get around and talk to everyone, and secondly after talking to all 20 testers, it gave me a pretty good idea of where the problem areas lay.

In John Stevenson’s article, he writes “Yeah xxxx was such a great tester but they had to move to development to be able to progress in the company”, and it was this line that I have heard repeated in one form or another several times. In our case it was either a move to development, or a move to project management. Both were seen as the only real progression for a test engineer.

This made me sad.

Then when I studied the data a bit more, a trend emerged that most of the test engineers who we hired as graduates 1-2 years ago are now interested in moving to development, whilst the 3-5 year testers are looking at project management.

So why do our testers with <2 years experience want to move to development? On further digging it became apparent that as the company has moved towards frequent releasing, the bias towards test automation has grown significantly. We have always been big on test automation, but now more so than ever. That, coupled with our teams running with very little slack time and an emphasis on releasing quickly, has meant that our fairly new testers have been doing test automation almost exclusively, with some mind-numbing pre-release manual regression testing thrown in.

Manual testing == Exploratory testing

Perhaps the desire to change roles is a consequence of this narrow view of the testing role. When asked about exploratory testing, a few of the testers claimed they did that on every release, but it was really boring and they were just doing the same thing over and over again.

It was at that point that I started to join up the dots. Perhaps the real issue was even if they did know what other areas of testing existed, they didn’t understand what they actually were. For example, in their eyes exploratory testing == manual testing, so if their only exposure to manual testing was the release checklist type regression testing, no wonder they wanted to jump ship!

So perhaps the real issue is one of education. As a company we have been working hard towards more frequent releases over the last couple of years, and encouraging teams to adapt their agile working practices to be more efficient. As a result, most of our teams have been running at full tilt for the vast majority of that time, allowing little slack time for learning and development. There are, of course, some people who will make time to learn stuff no matter what, but we should look at removing that ‘time’ barrier from the equation.

This was echoed by many of the testers when asked whether they were making any progress in their learning, with the common answer being, “No, I don’t have the time” or “There just isn’t time during the day to do it”.

Knowing what you don’t know

As a direct result of this survey, we are looking at ways in which we can introduce slack time into projects. There are lessons to be learnt from Google’s 20% time ‘policy’ which has recently made the news, and our own experiences, so we are confident we can put something in place. The work on this is ongoing.

But this on it’s own won’t solve the problem. How can you learn something if you don’t know what it is you should learn? There is one thing knowing ‘of’ the skill areas within the scope of your role, but what if you don’t even know that. Perhaps you consider yourself as an experienced tester, when in fact you are just simply not aware of some areas of your role. That may seem silly, but imagine you’ve had little exposure to the testing community outside of your little bubble in your team or even company, your big picture view of the role will likely be significantly cropped to the skills you are required to use on a daily basis. If we adopted the software craftsmanship approach, we have lots of apprentices, but very few journeymen and even fewer masters. This results in very scarce mentoring opportunities.

This brings me onto another major difference between developers and testers that I have suspected for a long time, but was qualified from our data. A developer typically played with computers as a kid, did computer studies at school, went on to doing a computer science or similar degree at university all with the goal of becoming a developer. They have that passion, that desire to do the job, and typically do programming in their own time (at least until marriage, kids etc!).

There is no university degree on software testing, there are no software testing classes at school and I’m pretty sure no-one has a burning desire as a child/teen/young adult to become a software tester. It’s sad to say that a fair amount of testers from way back when (myself included) got into the role because they weren’t quite wired like developers. The skills required to be a tester such as inquisitiveness, attention to detail, being able to look at the bigger picture (amongst many others) are traits I have always had, so thankfully this was a good thing.

However, I think that software testing is now viewed as a bona fide career in its own right, and many companies now don’t subscribe to the failed developer route.

But my point is that without that long burning desire to be a tester, a new tester has to learn pretty much everything from scratch, and that includes what skills are within the scope of the testing role.

And this is where I think we are going wrong. At my company, Developers and Testers are regarded on an equal footing, and indeed a lot of the skills are shared. However we treat new developers and testers the same, when perhaps there should be far more explanation of the role, skills, expectations, learning opportunities for the testers.

Skills map

In an effort to open the eyes of our testers to the skills encompassed by the testing role, we put together a skills map. At the centre of the map is a set of core skills that every test engineer should at least have a base level of knowledge in. Then radiating out from this are four quadrants. These quadrants identify directions an individual might which to take. They would still be a tester, but this would help to define what shape tester they are or want to become.Image may be NSFW.
Clik here to view.
test engineer skills map

By explicitly calling out the set of core skills such as exploratory testing, test techniques, issue reporting, pair testing, test automation, deliberate practice, giving feedback etc., it becomes far easier for the tester to identify what the scope of the role is, and which areas they need to focus on. It is very important that these core skills are learnt, practiced and honed before thinking about specialising.

This chart is being used in personal development conversations between testers and their line managers to help identify areas of strength/weakness and to generate actions for learning goals.

So what next?

We have tried this out on a few people, and we are still tweaking and improving (it’s the Agile way right?), but it’s looking promising as a tool to help drive the career progression discussions.

The hope is that some of the newer testers will look at the core skills section and identify several areas in which they need to improve.

There is certainly a long way to go with this, and we are not claiming this will be the answer to everything, but it’s a start.

If you have a story to tell or a point of view to share, we’d love to hear about it. Send it to us here!

About the Author

Chris George is Head of Test Engineering at Red Gate Software, working on tools for SQL/.NET Developers and DBA’s. He has been a tester/test manager with several companies since 1996 and specialises in test automation, specifically UI automation. He maintains a blog and you can follow him on twitter @chrisg0911

Chris George is also speaking at TestBash 3. Find out more and buy your ticket here.

The post Testing: An Obvious Career Choice appeared first on Ministry of Testing.


Viewing all articles
Browse latest Browse all 3

Trending Articles