Checking is easy. Deciding is the job.

I’m a QA engineer in Kraków, three years in — but I started on the other side of it, building front-ends for web apps and writing the automated tests for them in parallel. Two years of doing both at once is a useful way to find out which half you’d rather keep, and I kept the half that asks whether the thing actually works.

Not because I liked building less — the opposite. Inventing a feature and interrogating one are different work, and a full day of the first used up exactly what a side project runs on. Test automation is still programming, so the code never went anywhere, but it leaves the building appetite intact: this site is one of the things that came back, as is making things for other people when they ask. The front-end years earn their keep at work, too — I set up and debug my own environments instead of waiting on someone else, and when something’s genuinely outside my scope, I know exactly what to ask a developer for.

What I do now. Test automation, and the infrastructure underneath it — Playwright and Selenium suites across web and desktop, the CI pipelines that run them, the containerised environments they run in. The pipeline and the environment are the parts people tend to leave to someone else, and they’re the parts I want. Most of the work happens before any of it gets written, though: working out what the thing is supposed to do, and what is genuinely worth covering, reliably takes longer than the automation itself — more so now that I build agentically by default, and an agent takes the repetitive first pass while the judgment calls stay mine. That thinking is what keeps a suite from being a hundred tests that all share the same wrong assumption. A suite can’t tell you when that has happened, which is the same reason that when a test goes flaky, first I chase the root cause.

Not a solo job. Quality isn’t mine to own alone — it’s the whole team’s, and collaboration is what keeps it afloat. A test suite nobody else can read doesn’t help whoever inherits it, and a finding nobody acts on doesn’t help anyone — getting it actually fixed, not argued about, is as much the job as finding it in the first place.

Why security, and why DevOps. Not a change of direction — the same question aimed at a different threat model. Instead of is this feature broken, it’s is this control actually enforced, or does everyone just assume it is? It makes the testing better, which is most of why I went after it: a tester who knows what an attacker would try writes different cases, and a pipeline I can reason about end to end is one I can put real gates into rather than hand work off at the edge of. Wiring a scanner in isn’t the part I care about — that’s mechanical, and increasingly something an agent does unsupervised. What holds my attention is what comes after: deciding which finding is real, which one can wait, and which one means shipping stops today. That’s a call a tool can’t make on its own, and taking responsibility for it is the actual point.

Where I’m heading. Further into DevOps and application security, on the technical track — judgment and scope, not headcount. I’m studying Cybersecurity (Engineering studies) at UKEN alongside the job, not a generalist CS degree, working through the fundamentals properly rather than collecting badges. And I’m building the communication side just as deliberately, since a finding or a migration plan only matters once someone else acts on it.

Outside work: scale models, mostly cars and boats — and increasingly conferences, meetups, and summits. That’s where the connections actually happen, and eventually I’d like to be the one speaking from the stage instead of watching it.