DevTestOps is all the rage. And with good reason; delivering quality software at speed depends on it.

The problem many testers face though, is how to move from a job that focuses on manual testing, into a job that is more agile; more DevOps; more continuous test automation focused. More DevTestOps.

As with anything, there’s no silver bullet. But some of the ideas below might help you develop your skills in the right direction.

Keep working on your soft skills

Technical skills are important for your day-to-day testing efforts. But you shouldn’t underestimate how important your soft skills are too.

Chief among them are likely to be your ability to think critically and ask probing questions. But you’ll come up against a lot of brick walls if you aren’t able to ask those questions with degrees of diplomacy and sensitivity. Effective communication skills still rank highest amongst the most desirable workspace skills for virtually every conceivable role, and with good reason.

Leadership should be another consideration. In meetings, and when pushing for a bug to get fixed, testers must learn to fight their corner. Leadership doesn’t always mean being the loudest, or the one in command. I like the maxim “strong opinions, loosely held”; when a tester is aware of an important issue, they should do everything they can to shine the spotlight upon that issue, unless and until circumstances dictate otherwise.

Oftentimes, good communication goes hand in hand with leadership. Being able to use your words incisively, so they cut to the heart of an issue without offending anyone (at least, no more than necessary!) These are valuable skills.

And before I move on, for the avoidance of doubt, when I talk about communication, I mean the written as well as the spoken word. As remote working becomes more and more prevalent, the ability to communicate effectively via Slacks and emails is ever more crucial.

Learn the fundamentals of coding

Does every tester need to code? Probably not, but learning some of the basics surely won’t hurt either.

If you’re not sure where, or how to start coding, go for some quick wins. Pick up a book on Python or Ruby scripting and automate some activities that you find tiresome; learn how to rapidly create or analyse data using Python for example.

Once you’ve made some inroads, learn how to use a scripting language along with a testing tool. Again, an obvious place to start here is with Selenium - the most popular [automated] testing tool of them all. Learning how to use the Selenium API alongside your scripts will take you quite a ways in your automated testing career, but you shouldn’t stop there.

Build on your Selenium API knowledge by learning how to utilise other API’s too. Does the software you’re testing use an API? Think about how you can extend your testing coverage by focusing automated tests on the API instead of the UI. While we’re on the subject of using API’s – does your test management system have an API you can use to further manage and report on your testing activities? Start to think about plugging that into your automation framework too!

There’s plenty of other ways you can ramp-up your coding skills too. Probably you’re working more or less closely with some developers. Ask them to help you! Most developers will be happy to provide you with some pointers, and you’ll have the benefit of learning more about the tech stack your team is actually working with.

Another great place to start is by reading your teams pull requests. Even if you never actually write any code, learning to read it will be a great asset to you, and your team.

Optimise your tests

What does your team need the testing approach to do for them? That’s the question you should be trying to answer with your test plan.

For most DevOps teams, success is going to rely on your having automated as many of your tests as is possible. Not all of your tests can or should be automated though, and you should have a plan for any manual, exploratory testing that needs to get run as part of a sprint or release cycle.

I’d recommend layering your tests into different execution runs. You may choose to have a smoke or sanity test cycle which checks basic functionality for any regressions, before entering your main automation cycle – so as not to waste time running tests unnecessarily.

There’s several ways you can do this. Methods that I would particularly advocate for are either by prioritising your tests (so that you can execute tests according to their priority – which will help with your reporting, and management of resources too), or by labelling or categorising them into different types of execution: Smoke, Sanity & Regression for example, as I already mentioned.

You should be on the lookout for ways to improve your test approach, to minimise feedback cycles for your team. Keep your test cycles as short as you can – whether automated or not – so that your team gets the information they need, when they need it.

Fix automation bugs as soon as you find them

I want to give a hat-tip to Matt Archer here for the name of this section (he wrote some great content back in the day around fixing bugs as soon as you find them). Where automation bugs start occurring, you need to jump on them as quickly as possible.

Terminate automation bugs, with extreme prejudice! If you don’t, they can lead to a disastrous outcome to your automated testing efforts.

I’ve seen some unpleasant situations arise in the past, that have been rooted in issues with flakiness, unreliable environments or infrastructure and poor quality data. All problems that could have been resolved with committed and timely interventions, but instead were left to fester over time and which led to a failing test automation stack that wasn’t providing value for anyone.

It’s absolutely critical that you resolve these kinds of issues as soon as they come up.

Flaky tests are often the result of poorly written automated test implementations, or they may point to actual issues in the software they are supposed to be testing. Don’t write them off as a test that fails sometimes or ignore it. Do the work; investigate the issue and get to the root cause.

Infrastructure or environmental issues can be another order of magnitude. But it doesn’t mean the solution to those problems is out of your remit. If your automation can’t be run because of environmental issues, you need to get the environment fixed. Raise a bug for it. Make it a blocking issue. Call it out in your daily stand-ups, but make sure it gets the necessary attention.

Once your team is on the issue, think some more about how you are running your automated tests in the first place: Are you trying to cover too much in a single test? Are you targeting the automation at the right layer of the tech stack? Should you be running some more unit tests instead of API or UI tests?

In the worst case scenario, you should take automated tests that can’t be run successfully and add them to the manual stack of tests instead.

Get your head in the cloud

Each step I’ve mentioned above is going to take you from where you are now, to some other place along the DevTestOps continuum.

Hopefully, in terms of your career, following some of my advice is going to move your needle, from being a low-skilled manual tester, to being a highly-skilled and sought after DevOps test engineer.

Before you attain this lofty goal however, there’s a few more steps you’ll want to take. Principal among them is familiarising yourself with the various technologies that can be used to orchestrate containerised environments in which your software can be tested.

Confident control over those environments either locally or in the cloud, both for the software being tested and the software carrying out the testing will be a huge step further along your DevOps tester career continuum. So learn some Docker; learn some Kubernetes; get comfortable using AWS and Google Cloud, and enjoy the ride.

It’s a brave new DevTestOps world out there. But don’t worry; you got this!