I wasn't always drawn to technology. In fact, early on, I wasn't particularly technical at all. I didn't grow up coding, tinkering, or dreaming in algorithms. I scraped my way through my education in test and project management by doing the bare minimum. Not because I lacked ability, but because at that point, the spark simply wasn't there yet.
My first break came through an internship that eventually opened the door to an assignment at IKEA. There, I learned the basics of test automation by sitting close to experts. It was valuable - but I still didn't fully grasp the deeper purpose or the craft behind what I was doing.
I wasn't a model early-career professional either. I wasn't particularly reliable, nor fully invested. I was doing the work, but I wasn't yet connected to it.
My next chapter began when I joined System Verification and my assignment at Sony Ericsson. This time without experts guiding me. I could automate tests, technically, but the confidence and deeper understanding weren't there. Imposter syndrome set in hard. I heard people talk about processes, SDLC, waterfall vs. agile, DevOps principles - but the pieces weren't clicking yet. I was four years into the industry and still felt like I was missing the point.
Then came the assignment at Skånetrafiken, which became the turning point.
I was surrounded by experienced developers, test managers, and automation engineers who didn't just do the work; they understood it. This was where everything began to click. Code started making sense. Architecture wasn't abstract anymore. DevOps stopped being a buzzword and became a mindset. I shifted from simply executing tasks to seeing the whole system - and how quality fits inside it.
For me, quality engineering isn't defined by the tools or the frameworks. It's defined by the mindset that guides how we build software.
Quality starts with understanding purpose. Before diving into automation, pipelines, or architecture choices, I learned to step back and ask why the system exists, what risks matter most, and what value we aim to protect or deliver. Effective testing isn't just execution - it's alignment with the problem we're solving.
Quality lives in the intersection between what the business intends and how the system behaves. I discovered that my most valuable contribution was often in translation - ensuring user needs, architecture decisions, and technical workflows connect seamlessly. Great automation and DevOps practices are only meaningful when they reflect business reality.
Anyone can automate a test once. Craftsmanship means building automation and quality practices that remain understandable, adaptable, and useful months or years later. Clean code, simple interfaces, thoughtful naming, and maintainable pipelines aren't details - they are pillars of long-term quality.
These principles are what shifted my role from simply testing software to building confidence in software. They shaped my identity not just as a tester or automation engineer, but as a quality engineer - someone who helps teams deliver value with clarity, purpose, and sustainability.
For a deeper dive into these ideas, particularly how quality spreads through teams and culture, I often think back to discussions and concepts my colleague Tobias Anderson and I explored at Skånetrafiken.
Tobias's "Quality Osmosis" series is an excellent reflection of that philosophy, focusing on how quality grows through collaboration, shared understanding, and technical empathy across disciplines.
As I look back on the journey that shaped my understanding of quality, one truth stands out: the craft is more than tools and processes—it’s about curiosity, clarity, and connection. In the next part, I’ll explore what happens when growth challenges that connection, and how we can evolve without losing the work that made us love this field in the first place.