"I Did What I Liked and Got Paid for It Too": How to Transition from Manual to Automated Testing Without Suffering

"I worked as a receptionist manager at a hotel, where I hoped to practice English"

— I don't recall having specific career dreams while in school, apart from the typical childhood aspirations of becoming an astronaut or a firefighter. I studied more than average, but I wasn't reaching for the stars: I lacked the discipline to memorize the material necessary to be an honor student.

I entered the foreign languages department of the Francysk Skaryna University in Gomel, which, looking back, was an impulsive yet ultimately correct decision. It was largely thanks to my English that I later joined EPAM without any real tech experience.

Before EPAM, I worked as a receptionist manager at a hotel in Gomel, where I hoped — unfortunately in vain — to practice English. Before joining the hotel team, I applied for tester courses on the EPAM website. Actually, I applied and forgot; no one contacted me for over a year. One fine day, the HR department of EPAM’s Gomel office called me. I couldn't go to the first interview, so they "interviewed" me over the phone. Ironically, that was the first time in a year that I practiced English while working at the reception position. After that, I had a second interview, followed by the subsequent lab (EPAM educational courses), and finally, employment with EPAM.

"I was always the guy who installed Windows for my family and friends"

— If you ask me why I became a tester, the answer is mundane, unlike the job itself. I had no experience in tech, and being a tester had a lower entry barrier than the average position in the field. For the same reason, I chose manual testing rather than automation — and I had only a limited understanding of what it was. Before I started working, I didn't grasp how well-suited this job was for me. I was always the guy who installed Windows for my whole family and all my friends. I tinkered and tried to mod games, delved into config files to run a new game on my ancient hardware, disabling shaders. But I didn't know how to turn this hobby into a livelihood until EPAM showed me.

I didn't stay long in the lab, but it was productive time. I got acquainted with the basics of the craft beyond "Testing dot com" (from which I took perhaps one incomprehensible word, "spec"), wrote my first test cases, found my first bugs, and saw a stack trace for the first time and learned what it was. After the lab, I joined a small project where I've now been working for seven years, learning everything I could, and continuing to develop.

"How much more do I need to work before I start understanding something?"

— My initial impressions of manual testing are probably best summed up by the question I asked my resource manager at the coffee machine early in my professional journey: "How much more do I need to work before I start understanding something?" The work was difficult and unclear to me, but over time — and in 100% of cases — all the pieces fell into place. What I liked most about the job was that I was absorbing vast amounts of knowledge, and I finally felt like I was doing what I was supposed to do. I wasn't saving lives, of course, but I was where I needed to be. I was doing what I liked and getting paid for it!

I've been involved in manual testing for the past 7 years. The position and the required level and type of expertise changed with my transition to automation, but I am involved in the QA team's processes throughout a full QA cycle: from writing test cases, to testing them, and eventually automating them (although I often write tests and cover functionality first, and then write test cases).

"Our test rhombus didn't look like a test pyramid"

— The development of automation on the project (and my development along with it) was built in what seemed to us to be the path of least resistance. Initially, we wanted to reduce the regression load during releases of mobile applications. So, in our free time (read: non-working time), we started writing Appium tests for iOS and Android. Then, we expanded to Web-UI and Selenium. After that, we moved on to API. It was only after all of this that I started looking at the test pyramid and finally understood why it is the way it is – and that our test "rhombus" didn't quite fit.

During this process, there were many bumps along the road. Tests and frameworks had to be rewritten, and not just once or twice. We had to do our learning almost exclusively through our mistakes since there wasn't a separate team of automators to guide us in the right direction and offer advice. I frequently found myself in situations in which I was the only one who could answer my questions. As a result, I gained practical experience in independently solving problems of varied levels of complexity. Over time, I began to notice that even though I was considered a manual tester, a significant part of my working time was spent on automation. That's when I started thinking about an official transition.

"For those thinking of transitioning to automation, I have no easy solutions"

A specific motivation for transitioning to automation was my desire to move to the US. It was almost impossible to find a position as a manual tester, but it was a bit easier with automation. Since I had significant automation experience, I literally prepared in a week, passed the assessment, and got promoted from Lead Test Engineer to Senior Test Automation Engineer. My experience with manual testing and the theoretical foundation that I accumulated over the years played a significant role in the stress-free assessment.

For those thinking of transitioning to automation, I have no easy solutions. If automation brings you joy and it's "your thing" — go for it. You won't regret it! If my experience is any indicator, you're in for days, weeks, and months of taking hits and pushing through with a weak understanding of what's happening. Don't let this demotivate you! Enjoy every new piece of refactored "crooked code" that you write yourself. Find pleasure in the first bug, and all subsequent bugs, found by your poorly written tests. Appreciate those rare days when you rejoice in improving the architecture of your framework – until you get an idea about how to make it even better, and so on, in an endless loop.

I recommend, if possible, starting to automate on the project where you currently work, or finding a project where an automation option is available. No matter how strong your motivation is, you won't get far with pet projects, and real experience writing tests for a production application is irreplaceable. Only in “real world” conditions can you grow and develop.