Lately I've been trying to get more into the testing and quality side of the development lifecycle.
For most of my career, this wasn't something that mattered much. Small agencies just want the site delivered and working as expected. Quality is mostly a manual check before handover, done to minimise the issues a client might raise later. Nothing more systematic than that.
Even in slightly bigger setups, I only brushed against proper testing, usually for larger clients or more complex codebases. It was never baked into how we worked. It was a reaction to a third party's request, not a discipline in its own right.
What that did give me was some exposure to unit testing. I picked up a basic understanding of the common libraries and got into the habit of writing a few unit tests for each feature. But the habit never grew past the mechanical: I knew I was supposed to have some coverage, so I did. I never dug deeper than that.
I won't pretend I'm on my way to becoming an SDET or an expert on the subject. But I am starting to look at the whole thing with very different eyes.
The company I work for takes testing and quality seriously. We have a team of senior, highly skilled SDETs, each overseeing an area and acting as a direct reference for a team. To keep them from becoming a bottleneck, there's been a strong shift-left push over the past year. It empowers us developers to build quality and testing more deeply into our day-to-day, and it gave me the opening to actually get better at this.
I'll admit that for a large part of my career I found writing tests boring. An afterthought, something I'd often remember at the last minute before deploying. Deep down I knew that attitude was wrong. I just needed a reason to change it.
That reason arrived with a new SDET joining our team and the shift-left initiative ramping up. I decided it was time to start thinking like a professional about this. I didn't just want to write tests and get my PRs merged. I wanted to understand the reasoning behind it all, what we test, what we check, and why.
So I stepped outside my comfort zone and admitted, plainly, that I was bad at testing. I'd never worked alongside an SDET, I wanted to learn, and I apologised in advance for the dumb questions that were coming, because I needed to build a proper mental model from the ground up.
What I found was a much deeper and more interesting world than I'd expected. The discussions about what to test and why operate at a far higher level than just writing a pile of unit tests. Adding coverage for the sake of it, I learned, is really just code debt dressed up as quality. Those tests become tedious to maintain, and I noticed even AI models got less precise when they inferred too many constraints from over-specified tests.
Understanding a feature deeply enough to know what could actually go wrong, what you need to protect against, what must never regress, turns out to be a genuinely cerebral task. In a world where AI can churn out code endlessly, these conversations about what a feature truly means made me appreciate the craft behind my job more than I had in a long time.
And it didn't stop at unit tests. I got introduced to the wider world of e2e tests, smoke tests, failing pipelines, Cypress frustrations, Playwright POCs. I'll admit I'm still mostly listening during these sessions. But I can't forget where I'm coming from. A few months ago I barely understood the testing structure. I jammed in a few unit cases with the sole aim of closing the ticket.
Now I feel far more aligned. Every PR is a chance to pick up another nuance of how we hold quality to the standard the company expects. I'm slowly able to make better calls without asking, and things that were opaque are starting to make sense.
I won't become an SDET. But I can promise you I'm on the path to becoming a better developer.