Most startups begin with a “DIY” testing setup. Founders and devs doing their own testing.
I’m curious if anyone has seen that approach successfully scale as the company grows.
There’s a lot of excitement around automation, CI/CD, DevOps, TDD, etc., but I don’t think those truly replace a dedicated testing process. They work… until they don’t.
How do you get stakeholders to recognize when it’s time to shift and that it’s not just a “gap” in the DIY process, but a necessary evolution toward dedicated testing as the product scales?
I won’t address the „when it’s time to switch” part, only the „can it scale w/o a dedicated QE role”
Here are two posts from Gergely about this topic. One mentions QA in general and how some large companies avoid a dedicated testing role altogether, and the second one talks about Microsoft’s departure from the SDET role entirely. This is to claim that apparently sometimes it does scale and those companies apparently can get away without a dedicated role:
Start-ups and some organizations looking to cut cost would hardly see the value of investing on testing, if they don’t experience production incidents regularly. However, the fact that something hasn’t happened doesn’t mean the risk of it happening isn’t there. So, as a quality interested person, I often see myself and my role as that which is meant to help others see those risks even when they aren’t apparent to them.
Therefore, in your example above: I suppose my starting point would be to help the organization see the risks, of how things can go wrong, the impact those things can have on the business, and how testing can help or be a mitigating action.
One way I have done this in the past, is by creating a record of reported production bugs for a given product, making an analysis of their impact, and showing the result of my analysis to the stakeholders who cares, not just about quality, but also the success of the business.
I was lucky in my current organisation. As a startup, they had recruited previous to me a couple of testers and knew early on that they needed someone to give direction on how to scale the testing effort. So I had a voice from the beginning.
So I found when breaking down each objective they wanted me to achieve, I could isolate each one and use it as a direction of travel. As an example we had contracts that required test reporting, compliance to industry standards, complex product integrations etc. and I could use those to cut through the initial “Automate everything!” demands and focus on the processes we would need that could be backed up with people and tooling. So the dedicated testing naturally evolves.
I stress the word “evolve” as each step will uncover a hole or a silo that will need addressing. Its never simple, and it requires dedicated leadership to see it through long term.