Before 2022, quality assurance at my company wasn't really a function — it was whatever developers caught before shipping, and whatever users reported after. No dedicated team, no process, no shared definition of "done."
Where I started
I wasn't chasing this role — I was assigned to it. The company designated me as PIC to explore QA as a function, since one basically didn't exist yet. So I started where any exploration starts: with the basics. I began writing test cases myself, trying to figure out what even made a test case good, then worked out a standard for how they should be written so anyone could follow the same format. Alongside that, I built out a list of what actually needed testing — because before that, coverage was more instinct than system.
To go deeper than trial and error, I enrolled myself in an automation testing bootcamp on my own initiative, specifically to sharpen the QA fundamentals I was still filling in as I went.
What I actually built
- A standardized bug-tracking workflow so issues didn't just live in someone's head or a random Slack thread.
- Test documentation templates that made it possible for anyone — not just me — to write a consistent test case.
- A defect-tracking pipeline tied into how development actually shipped code, not a theoretical "best practice" copy-pasted from a blog post.
None of this was glamorous. Most of it was just making sure the same five problems stopped happening every sprint.
Growing a team around it
Once the process existed, I needed people to run it. I recruited and mentored the first QA hires and interns — which meant I spent as much time teaching why we test this way as I did reviewing actual test cases. The hardest part wasn't the tooling. It was getting developers and QA to trust each other's judgment instead of treating testing as a gate at the end of the pipeline.
What I'd tell someone starting this today
- Don't design the "perfect" process first — design the smallest process that fixes your biggest recurring problem, then iterate.
- Documentation only works if it's easier to follow than to skip — if your templates create more friction than they remove, people will route around them.
- The goal isn't zero bugs. It's fewer bugs reaching users, caught earlier, by a team that knows why they're testing — not just what.
A few years later, that one-person exploration grew into two teams I now lead. The function that didn't exist became one of the reasons releases are boring now — which, in QA, is the biggest compliment there is.
PS: I still have the very first test case template I wrote. It's embarrassingly basic compared to what we use now — which is exactly the point.