From Support to QA: A Journey in Testing

I didn’t start working in QA until relatively late in my tech career. I started as a helpdesk support bod before moving into system administration supporting a Windows environment. Reflecting back on it now, I realize that I must have done some elements of a Quality Assurance (QA) job, by testing software that was due to be used by the company or staggered rollouts of patches to identify potential risks… But I never really thought about QA as a career. For that matter, I didn’t really know what a QA did!

Before I moved to QA, I had started to be completely disillusioned with the world of the sysadmin. Microsoft seemed determined to push sysadmins towards using PowerShell to script everything and I wasn’t interested in coding or development. That will come back to haunt me later… The director of development at the time was a forceful character. We had clashed on a number of occasions when I was asked to do tasks that went against the security of my domain. It came as a total surprise when he told me I might make a good QA and would I be interested in moving to the development team. I said I would think about it, then frantically tried to find out what a QA did.

After coming to a rough understanding of what a QA does, I decided to accept and became a senior QA. I ended up amongst three other QA’s and it was a pretty steep learning curve. I also had to deal with some suspicion amongst the developers, as I had previously been an adversary and now, I was sitting among them.

The company at the time was largely web-based so we did a lot of browser testing and occasionally, some mobile testing when we were developing an app. Everything went along fairly happily, except for a reasonably high turnover of QA’s. I think I went through three or four colleagues in my first couple of years. Among our numerous projects, we started producing a piece of software to help students gathering references and then input them into their dissertations. This broadened the scope of our testing from web only to web, PC, Mac, and mobile devices.

Our development methodology was a rough combination of scrum and Kanban, so this was my first introduction to Agile. This was completely new to us, but we got work done and thanks to the efforts of a talented development team and a group of dedicated QAs, we did good work.

But here is where the haunting mentioned previously comes in… With a growing estate and product base, we needed to start looking at automation – coding and all. I mentioned that I moved away from sysadmin in order to avoid coding, well here I was again. This time, I tried to learn Java and it was horrible. I did not do very well, and I started to believe that people are either born naturally able to understand it quickly or they have to work to understand it. I was in the second category. At that time, test automation was Java, Cucumber, and web driver. For me, it seemed difficult to understand and even harder to implement but I learned.

Because of the workload, the priority was always manual testing, so I had plenty of work to do. I always viewed the team leader’s role as being able to delegate and trust the people who were working for me as well as to act as a shield if something went badly. So, by that time I became a team leader, with four people working for me, I always took responsibility and tried to help the team learn from experiences.

Team leading was fun for a while but I was started to feel the need to move on in order to grow as a QA. I started applying for roles and, after some time, I was picked up by a large financial services company that had a very well-structured development methodology. It was a bit of a shock to me at first, but it taught me a lot.

While working at that firm, I moved teams four times in two years. I got a reputation as someone who wasn’t afraid to ask questions and suggest alternatives or improvements if I felt they were needed. My time there included working on Salesforce, iOS an American-based trading exchange, and lastly a design-led team looking to improve customer experience by extensive research and open team dialogue. It was a great team to work for, and so much interesting work. It was also where I first came across Cypress, which was to revolutionise my experience with test automation.

Sadly, my time there came to an abrupt end with a redundancy based on a lack of experience in automation and a desire by the head of QA to move to 100% automation. I can accept that manual testers are not as relevant as they used to be, but manual testing will always be needed. Will a developer in test want to do manual testing or will they want to code? After all, that’s their skill set.

After a month-long panic about what I was going to do, I was finally offered a role as a team lead for a company that supplies payment services for cinemas and gyms. At first, I thought that it wasn’t exactly a great move at the start of a global pandemic that saw gyms and cinemas closing for long periods, but it has probably been the best move of my career.

I am now implementing a QA function from scratch alongside a team of people implementing Agile processes from scratch. The QA side started slowly there but has gained strength in the past few months as my colleague, whom I have never met face to face, and I have gotten to grips with the products and people we’re supporting. We’ve implemented an automated testing framework using Cypress which, because of the ease of use, has allowed me to write fully working end-to-end tests with little or no coding experience. Although I have previously said I didn’t want to code, I am now finding myself writing tests for fun! With my exposure to API testing with Postman and configuring Jenkins jobs, I can now honestly say that I am having the time of my life!

QA is a difficult job. We’re the bottleneck causing troublemakers but what we do is vital to every company, big or small. We make sure the product does what the customer expects, and we help maintain the company’s professional brand image.

All in all, I really like what I do. I think it has value and, although it is sometimes frustrating, seeing a product launched when you know you’ve had a hand in making it work properly is very satisfying! I am still holding out for that lottery win, though…!


Written by Ed Aldridge, IT QA Lead

Related Posts