It's hard to believe how quickly a year has gone by. When I took my first steps in test automation at b.ignited, I had no idea what to expect. I was ready to dive into testing, but what I found was so much more. A year later, I’m looking back at a ride that’s been full of surprises. From scripting tests to building frameworks, from learning new technologies to developing soft skills, this year has developed my perspective on both my career and myself. So, let’s take a moment to reflect on how far I've come and what’s next on the horizon! 

Not what I expected 

To understand why this job was nothing like I expected, we’ve gotta rewind a bit, back to my college days. I studied computer science, where I learned a lot about software development and got my introduction to the infamous Test-Driven Development (TDD) feedback loop. If you’ve never experienced it, here’s the basis: write a unit test, watch it fail, and then code until it passes. Repeat. 

Now, at the time, TDD and API tests were all I knew about testing. I understood it, but I didn’t love it. Honestly, I’m pretty sure most computer science students know the feeling: testing is just that chore you have to do, and even if you do TDD, it’s not something you would jump for. And let’s be honest, who actually does TDD? Right. 

Fast forward to graduation. I joined b.ignited as a test automation engineer but with my sights set on becoming a software developer eventually. Or so I thought… Plot twist! Now, a year in, I’m unsure about that whole “software developer” plan. I mean, am I already a developer? Or something else entirely? It’s hard to say. 

Let’s rewind again to my first day at b.ignited. I showed up figuring my job would be straightforward, maybe something like the unit testing I knew from college. I imagined I’d just be scripting little checks here and there, making sure each part of the code was doing what it was supposed to do. Simple, right? 

Wow, was I wrong. Test automation isn’t just about testing isolated bits of code. It’s about scripting entire processes and functionalities across applications. And as if that weren’t enough, there’s an additional layer of complexity involved in building frameworks to support those tests. A whole new world of automation just opened up to me I was barely through my first week when I realized just how wrong I had been. 

I quickly became deeply immersed in framework architecture. Learning what made these systems work perfectly. And, to my surprise, I couldn’t get enough. Building and designing frameworks quickly became my interest. I was always trying to make them run faster, work smarter, cleaner, or just be better. “Test automation” didn’t feel like the right term for what I was doing anymore. It felt like I’d been given endless opportunities to learn, and I couldn’t get enough of it. 

And that wasn’t even half of it. The team at b.ignited didn’t just let me do classic testing tasks, they had me working with all kinds of new tech. New frameworks, modern programming styles, cloud services,... You name it. I felt like I was doing more than just testing. I was building, and innovating. Learning to problem-solve at a whole new level. 

You’re as important 

If there’s one thing I’ve learned in test automation, it’s that testing isn’t always the star of the show. But it should be. Testing might not get a standing ovation, but when you really get down to it, it is as crucial as the code itself. This job quickly taught me that sometimes, the biggest challenge isn’t just doing the work but proving why the work matters. 

In my first year, I had to become not just a test automator, but a bit of a testing representative as well. When you’re the one motivating for quality, there’s this invisible line where you have to stand your ground. At times, it involves sitting in a meeting, hearing discussions about tight deadlines, and speaking up to say, “Yes, we could skip these tests… but are we prepared to handle bugs down the line?” 

An example of this was when I wrote tests for a testing-framework. That’s right, I wrote unit tests for code that was testing other code! There I was, explaining why these tests were necessary, that it wasn’t just another “nice-to-have” but a fundamental part of ensuring the whole framework held together. Defending your decisions becomes a fundamental part of the job. But so is learning to accept letting go of your personal desires. Maybe there just really isn’t time. Or sometimes you’re building code that needs way too much maintenance so it outweighs the added value. It’s a continuous lesson to build balance between motivating why something matters and letting go for the sake of the project. 

Growth in every direction 

I’ve learned a lot. A LOT. On every level. It was like every month brought a new challenge, a new tool, a new programming language, or a new soft skill I never knew I needed. And the best part? I felt getting better, every single time. I became more independent and more confident in my role. 

Remember the previous part? I quickly realized that soft skills were just as crucial. Communication turned out to be a huge part of the job. Test automation isn’t just test automation. You need to explain your approach, justify your decisions, and sometimes even convince others why certain tests or framework improvements are necessary. It’s a different kind of skill-building. Learning to listen, use the right words, and convince others of the value of your work. Even if those people might not see the importance of your work at first. 

This year taught me that growing in test automation doesn’t mean becoming perfect at one skill. It’s about being adaptable and ready for whatever new tools, tech, or conversations that cross your path. I’m now a far more well-rounded coder than I was a year ago, and it’s not just the programming languages or frameworks that make me better at my job, it’s all those soft skills that I picked up along the way. Already looking forward to what I’ll be learning next year. 

Learning more about myself 

In college, they’ll warn you about something: “In IT, you’ll be learning forever”. So I was prepared to learn a lot. But what I didn’t see coming was how much I’d learn about myself. I figured out what I’m really passionate about. Where I’m strongest and where my limits are. 

One big thing I discovered was framework development. The more I dug into it, the more it felt like this perfect combination of creativity and logic. I found myself constantly thinking about how to make these frameworks faster, cleaner, and better. The architecture, the design choices, and even the tiny details. It all just clicked for me in a way I never expected. 

And this whole experience changed my perspective on where I want to go in my career. Originally, I thought of test automation as this starting point toward traditional software development. But now? Now I’m not so sure I want to move on at all. Building frameworks, working in automation, and seeing the direct impact of my work on quality. It feels great. It feels like my work has meaning. In a way, this role made me rethink what “development” actually means to me. I’m coding, solving complex problems, and creating systems. I’m developing… Just in a slightly different way than I originally planned. 

A final word 

This year has been amazing, and looking back, it’s hard to believe how far I’ve come and how much I’ve grown. I came into this role expecting to be someone who simply “tests”. What I found instead was a path that is unique. A path that merges development, problem-solving, and quality. Test automation pushes me to be better, to learn more, and to innovate in ways I never thought possible. 

I know now that this is only the beginning. The skills I’ve gained, the lessons I’ve learned, and the insights I’ve gathered about myself are all things I’m carrying in my baggage of experience.

I’m excited for what’s next. Here’s to the next year, to more challenges, more growth, and endless possibilities!