top of page
vgfd-Edited-Final (1).jpg

How Switching From Dev to QA Automation Changed The Way I Work

All of us (well, almost all) work as programmers and love it when after a lot of work and the completion of a project we look back at the fulfilled tasks / written code and take pride in our work. However, there is a flip side to it. It often happens that after having worked on a project for a long time, you start to feel bored. Everything seems familiar; you get new tasks, but their basic nature is the same.

Wait, when did my work become so boring?

At such moments some people ask to be transferred to a new project. Others even change their jobs not so much to get a higher salary as to feel this change of pace by getting involved in something new they have never tried before.

This is a post about how I felt bored in the same way about six months ago. I looked for something completely different because I wanted to try things I had never done before. I had been working on a large project for a year and it was far from being completed. I can’t say I didn’t like it. Both the clients and the team were nice, but it had been ages since I felt enthusiastic or thrilled when starting another task.

Switching to the dark side

It should be mentioned that we all work on our projects as a single Agile team. One of the principles of agile methodologies is that people don’t have fixed roles: anybody can perform any task. Thus, it is quite possible to migrate within a project from mobile development to testing or frontend development, or to writing a server.

So, one day I asked myself how I could change my daily routine. That’s how I got the idea to be a QA engineer for a while (I’d rather say “develop the field of automatic testing”). Thus, having discussed it with the team, I got the green light and turned to the dark side of testing.

Guess what? It worked! In fact, during the first weeks it was very unusual to find a bug and not fix it on the spot. I repeatedly caught myself diving into the code to find the cause. I had a vague notion of how I wanted automatic testing to work, but I couldn’t imagine that all that job would open up a whole new world to me, one of DevOps, configuration of CI, the search for existing solutions and open source libraries for running tests, which would make it possible to test the entire system at the user scenario level. As we work on a large and complicated system that involves the interaction of multiple applications, the written tests had to check the main user scenarios, and it always involved several different apps.

Those who are professionally engaged in mobile development should know that there are infinite solutions and ways of testing an app on a device – from frameworks included in SDK to third party services that test applications on many devices. What is the disadvantage of this variety? All these approaches are customized for one app which needs to be tested. But what if you have a dozen of such apps on your device and need to test a scenario that involves their interaction? It becomes more complex. Fortunately, there are solutions for such cases as well, offered by both the framework and open source libraries.

There is Jenkins running tasks that trigger written acceptance tests night after night. There are physical devices connected to the computer with these tests running on them. As I have already mentioned, the project has its peculiarities (we have to work with many apps simultaneously rather than with one app), so the main idea behind these acceptance tests was to check interaction between different apps.

Did this new role involve a lot of programming? Well, I did write quite a bit of the code. Was it difficult? No, it wasn’t.

Anyone who has had to write similar tests will confirm that the set of classes and operations is about the same. You don’t have to invent grand architectural solutions or use patterns right and left.

But the most important question is whether it was interesting and allowed me to challenge myself. Yes, it totally did. Was it interesting? Yes. I wouldn’t say that writing tests itself was very interesting, but working on something new gave me inspiration.

What about now?

The short answer is that I’ve switched back to programming. No, it wasn’t because I had nothing to do or because automatic testing could not be developed further within our project. The main reason was my desire to contribute to the project. Thus, you need always think about what would be the best for the project. At some point my team understood that we lacked people in the development sector, so I returned to my native environment.

It is quite possible that one day I will switch back to testing once again. After all, there are a lot of ideas about how to improve existing tests, what to add, and so on. Or maybe it will be done by some of my colleagues, who will also feel the need for a change and some “fresh air” and will take over my work.


bottom of page