Transitioning from software test engineering to DevOps

A career path in tech doesn’t have to be linear. After building a successful 10 year career in software test engineering, I’m excited to be forging a new career path in DevOps at Simply Business.

In this post, I’ll talk about my journey in software test engineering and how what I’ve learned has enabled me to transition to an engineering role in DevOps.

What does it mean to be a software test engineer?

“What is it you do for a living?”, asks Peter (not his real name), a 34 year-old senior marketing manager who I matched with on Tinder. “I break websites.”, I reply. Peter responds, “Oh cool. Like a hacker?” To which I politely burst that bubble with, “No, not quite.”

I’ve worked as a software test engineer for over 10 years and to this day, I find it difficult to describe to people outside of the technology industry exactly what the job entails. To some, I might sound like Angelina Jolie from the movie Hackers, or to my 60-something year-old parents, I “work with computers” and am definitely the best person to reach out to when their printer stops working at 10.43pm on a Tuesday evening.

It’s not easy to define the role of a software test engineer because it can often feel like being a jack of all trades, master of none. When you join a new company, your first task is usually to learn how an application is built, how it functions and then begin to think about how you can ‘break’ it. It becomes your role to understand how a new feature will work. You’re then tasked with going from A to B (from start-to-finish in the user journey) using or including that feature.

Sounds simple, right? However, the reality is that it’s more like travelling from A to B in 1001 different ways. That’s because the user, let’s call her Margaret, could use an app or a website in a very different way from many other users. Given that, your role as a software test engineer is to make sure you’ve thought of as many different ways as possible as to how users might use the application. Ultimately, what a software company wants is that all users can get to point B, the end of the journey. But as a software test engineer, you want the journey from A to B to be as flawless, seamless, stunning and wonderful as it can be for every user.

Front-line defence

Something I have as yet been unable to do in my career is to come up with a strategy or a way of successfully navigating a discussion that changes some of the perceptions around testing into more positive territory. This has occasionally led to feeling the need to justify my job and to prove why testing is such an important part of software development. It can even feel as if software testing is an afterthought or even a bit of a burden.

The reality is that a software test engineer is an essential part of the defence mechanism for preventing any nasty bugs from getting out into the public domain or, worse, from accidentally bringing an entire site or application down. As a software test engineer, you are, however, not only part of the defence system but are often the last person to use a new feature before it reaches the public. This can add pressure to what might already be a stressful task. A software engineer will be waiting, ready and poised to merge their changes to go live. It’s your job to tell someone to pull the trigger. You may also be working as the only software test engineer in a team, so you have to be very sure of your own abilities as well as being confident that you’ve checked the areas of the application that are most at risk or have the most vulnerabilities.

Dealing with imposter syndrome

I never went to university. I never studied computer science. I started out as a games tester 10 years ago, learnt on the job and worked my way to becoming a senior test engineer. I put this down to improving my technical understanding, to building connections, and a willingness to share cupcakes. It’s surprising how connections can be made over conversations and some sponge cake that has a dollop of frosting on top.

However, something I struggled with during those 10 years was imposter syndrome. I would often worry that some day I’d turn up for work and someone would call me out for being a fraud. Whenever I attended conferences or talks, I’d worry about people asking me technical questions because I feared that I’d be ‘found out’. I do think that the tech industry as a whole still doesn’t know how best to support software test engineers in their career. This can sometimes be reflected in how much training is available, with testers being the primary candidates.

Similarly, when referring to ‘tech’, we don’t often think of testing but more of developing. This is not a criticism. Just an observation. I’ve also found that, as web development becomes more complex, the intensity of imposter syndrome can increase. The way in which we test an application is changing to match the way in which we build our applications. As we shift from old ways and monolithic applications, to new ways that focus on building communication between microservices and APIs, I hope that we can support software test engineers and prepare all disciplines in the best way we can, so that no one is left behind. We are only as strong as our weakest link.

Being accountable

I once had an article written about me that was published in the Daily Mail Online. A great piece of advice that someone gave me when that article was published was, “Don’t read the comments section.” There’s a good reason for that. People can be mean, especially online. A lack of accountability means that people often say how they feel without fear of the ramifications but also without any thought for the person on the receiving end.

I would pass on the advice I was given to other software test engineers. One thing you learn not to do is to read the reviews of an application or website you’ve worked on. This is mainly because if something does go wrong with an application, it’s often QA that is thrown under the bus by the general public, or, in some cases, by the company.

Within a software company, we know that a piece of work has been through risk analysis, refinement, has had code written by an engineer, code reviewed by multiple engineers and analysed by a test engineer. Unfortunately, the general public won’t see it that way. I, also, don’t see it that way. The truth is that I’d feel that I’d let the team down if software was released and caused our application to respond in a way that says, “Computer says no.” In situations like this, you do pick yourself up, learn from your mistakes and improve going forward, but these experiences are always a bitter pill to swallow.

A new chapter in DevOps

I fell into testing. It’s not necessarily something I had planned to do as a career. Do I regret the decision to pursue it? Absolutely not. Each decision has led me to where I am now. It has led me to my next challenge. As I write this, I begin to wind down my 10 year career as a tester and look to walk a new path as Junior DevOps Engineer. I’ve been offered a secondment within DevOps at Simply Business and am incredibly grateful for the opportunity. I’m nervous but excited to see what awaits in the land of AWS, amongst other things!