I had no idea what to expect
when I first applied to be a QA engineer at Playtech - I didn’t even fully
understand my department- Information Management Solution. After four months of
working here (and an internship) I am still learning new things every day and
have the pleasure of working on tasks where I feel like I am becoming quite
knowledgeable as well as on tasks where everything is new. Even during my time working
as an intern I did not fully grasp how massive our service is. After finishing
my internship, I decided to focus on school. However, I was offered part-time
work just at the right moment, when I felt my work would only support what I
learned at the university.
Fun team events are important part of the work culture.
I doubt many people remember what they felt when they first learned how to ride a bike, but I am sure anyone can recall the last time they had to learn something new and later felt the pleasure of looking back on the learning process. I sometimes cannot even believe how much I struggled with tasks that seem so simple now.
This is how I feel about working as a QA engineer in Playtech – every new task is like a puzzle where I must figure out how to get the complete picture. When you finally get to see the whole picture, it is highly satisfying.
To continue with the puzzle analogy, I would like to list some puzzles I feel like I have completed or at least am still completing:
- API testing: something I have spent most of my time on and which has become the best tool for understanding how we handle data. While I had learned about different types of HTTP requests while studying at the university, I had never really played around with different types of requests and request bodies. After my internship, one of my first tasks was a straightforward constraint test which I did in our testing UI. After finishing my task, I remember being given a hint: “You know, you should always test these things with an API call as well”, and so I got to write my very first defect as a QA engineer, not just an intern. At that moment, I realized that however well something might seem to work, a good QA engineer always needs to know how and why they do.
- Understanding financial logic: as someone who had minimal knowledge about finance, learning the basics of financial transactions and accounting happened very quickly alongside testing tasks. Obviously, I still don’t grasp the massive amount of different formulas from which we get data.
- Working on automatic test flows with automation engineers: this is probably a favorite for many QA engineers. These tasks consist of understanding how a test would be run and how to best describe it to automation developers – you are giving them an exercise, and they are solving it by coding tests based on your description. Our QA teams are constantly working on improving testing processes, which ultimately means automating manual tasks. This is good news for testers since this leaves us with more time to be sure that processes that cannot be automated are working correctly and are also using the best solutions for our clients.
- Technological communication skills: almost every task requires close teamwork with developers and QA engineers from other services. Everyone is always willing to help and take a moment to teach others. Therefore, learning how to effectively communicate your issues or questions is a valuable skill that will transfer to your daily life. Someday, you will be the one helping others in understanding the same problems. This is ultimately the place where the need to understand the tasks you are testing comes into play. The saying “Give a man a fish, he will be fed for a day, teach a man to fish and he will be fed for a lifetime” holds true in our daily work.
- Connecting the dots on how services are intertwined: this means working with different database management systems, all of which are ultimately connected in one way or another. The variety of different testing applications, understanding how they are connected to the bigger picture gives us as QA-s a lot of options to test something. Most of the time, even though the general way to test a task is in place, you still have free rein to figure out how to complete subtasks – I’ve written Excel macros to make handling data for me easier. However, another QA might use a completely different approach for solving the task.
I feel like the job title
“QA engineer” fits the type of work we do well. Even though what I do is
assuring quality, at the same time I’m an engineer figuring out ways to break a
system and being knowledgeable about every service or not being afraid to ask
for help. I feel that while I perform tests for developments, ultimately, I and
my abilities are also tested by them –which makes for a job that is always
interesting and challenging.