Automation was all about an inner quality in the end

In this story, I want to share a little bit about what I do for a job that goes very much in line with a personal quality, or at least this is what I came to realize after some years in the field.

During these past years, I’ve been working as a test automation engineer — or any similar wording that you can think of. As it reads, I usually fall on the quality side of software development with a strong focus on automation. Thank goodness, in software, there is never-ending room for automation.

Like many QA automation fellows, I started as a — manual — QA engineer in a software consulting company. Of course, during the first months, you get to learn a lot; test plans, test coverage, testing cycles, equivalence classes, boundary value analysis… How to report a bug, and how not to. How to deal with the dev team and why it’s better to share a common space. I found it quite interesting, also because by then I wasn’t pretty much into coding and it sparked my curiosity. QA goes hand in hand with curiosity.

Yes, here comes the but. At some point, I found myself repeatedly running through long test plans, the infamous test cycles. So, we were doing these bi-weekly releases and we had to manually check the whole test suite like 2, 3, or 4 times per release…

How did it go from all about curiosity to repeated cycles so fast? That certainly killed it. So my natural reaction was, I need to do something else, either to expand my current capabilities or move into a new field. It was then when I started reading and learning about test automation and it completely got me, especially because it sounded too well and it would kill the repetitive downside of it. When you see and try both options it is crystal clear how much value you add when you get your tests automated. Surely I knew about it when I started in the field, but by then it seemed so complex and distant that I didn’t even consider it. So I got hands on it.

📢 “What is this black magic?”

For sure I needed to catch up with some programming stuff I learned back at the university, aside from reading a lot of posts and going to tech talks. But it completely paid off, and then I started thinking, how much time did I lose at work testing things manually in repeated cycles? Of course, this is not every QA’s experience and thinking! If you manage to keep it on the curiosity side and away from repetitive tasks, one can perfectly go on with it and end up being a key player in a team. But it was not my case, and I’m happy with how it worked.

Also during my personal upgrade to automation, CI/CD systems were starting to be a real thing and that meant things were going to get harsh for manual testing. How would I be able to keep up with manual testing in continuous integration systems? The move had total sense.

📢 “Ok, bring it on!”

So first you focus on one language and try to master it. Never made it yet. I shifted from one language to another until I found one I’m comfortable with, and after a while, you realize that you don’t have to be a rock star as long as you keep pushing and providing value. Well… and learning, you have to be comfortable with that as well.

Also, frontend or backend? You get hands-on one approach, see all the upsides and downsides, then you try the other layer as well and compare… In my case, I don’t have a strong preference for any, but I do think that it is good to try both and have the whole perspective. Depending on how the application works and the team’s dynamics you might be more inclined to do more backend tests, or the other way round.

With time I also got more exposed to CI/CD systems and tried to make them part of my game, “to automate my test automations”. That sounded quite well and realized that SRE/DevOps colleagues are one of my best allies.

📢 “Ok now, this is cool…”

Viewing it in perspective, this has paid off so much and so well that I can’t see why one would reject it. It is true that you need to invest some time in the beginning, but once it is up and running it’s all benefits, and that includes the time you spend fixing failing tests.

This game is all about long-term investment, something that I particularly try to foster in any aspect of my life I am capable of: purchasing goods (cost vs expected use time) or learning material (courses, books, even tv shows…), mundane daily activities (vacuum cleaning delegated to a Xiaomi robot), investments (robo-advisors for index funds with worldwide presence)... Maybe I enjoy it because it goes hand in hand with my thinking? I have to recognize it too; I am a bit of a lazy person and get quite annoyed when I have to do repetitive tasks, but hey, that can be the trigger to force yourself out of it and focus on what you really want.

Sometimes I thought it was my job that drove me to be this picky in terms of time-saving in my personal life, but deep inside, I believe it is the other way round. If I lacked this thinking, I’d never had made the professional move. This was the trigger of all this. It can be true that now, the professional side spread to the personal one and a snow-ball effect started therein. But this snow-ball would never get any bigger if I didn’t grow this quality within me. My belief is that I share this with many colleagues that work on automation, not only speaking about testing. When you enjoy what you do in your job, or at least the philosophy underneath, at some point you realize that you have it present in your daily life.

Now, at Coverwallet we try to push the same philosophy since our very aim is to simplify and ease the whole process of finding and providing insurance coverage for businesses using technology and an intuitive UI. When you realize how much time it can take for a business to find proper coverage and to get all the related documents, you see how much room there is for automation and I’m only speaking about the process here. Focusing on the test side alone, we’ve got quite some frontend applications, a myriad of backend services, third-party integrations with carriers, payment platforms, CRMs, data platforms, identity providers… All this means that we need a lot of automated tests to be able to track the status, using different approaches for every part of the application and the most difficult part of it, balancing it all and providing visibility to the tribes to be able to react quickly. It sounds fearsome and exciting at the same time, but if you share the view it can be a lot of fun too.

If you got until this point, thank you for reading! I hope you enjoyed it and I would like to hear other’s opinions on this. Meanwhile, I’m back to my testing stuff. During the time I took to write this post (writing time) several hundred tests run in different environments and I’ve got to have a look at some of the failing ones.

Cheers!