If you don't do it, you'll have no enforcement arm to make devs care about maintainable infrastructure or Quality of User Experience. Your tech stack will be driven by whatever whizbang your devs that actually matter want to do will-o-the-wisp style, and over time, as complexity ramps up you'll be left with a bunch of teams that know their microcosm, but not how everything fits together, and next to no one willing to actually dig into the shittier parts of the codebase.
If you hire some QA, but only enough to keep every one of them tasked 100%, no downtime, no training/learning time, no redundancy, you've got QA for maybe 1 and a half to 2 years tops. Your entire QA group will see through any lip service that management pays to Quality Assurance, no long term investments in knowledgebase, preservation of tribal knowledge, or keeping the Quality bar raised up higher than it's original set point as people start attritioning out.
This will start to be reflected in an increase in prod issues, slower defect resolution, poorer user experience, decreased morale, more miscommunications over time, and loss of cohesion.
My point is this. Quality is either something you commit to, or you don't. You can pay it lip service, but your customers will know you didn't.
I've seen it played out time and time again. Don't take my word for it though. Spend a couple years to paying attention to rediscover it if you want; just remember whose responsibility it was for making the decision to not make nice things. Your QA people are the only ones charged with being an organizational conscience on the behalf of your users. Proceed without it at your own risk.
Everyone says they hold Quality in high regard, but then when it comes time to do the work, everyone takes every escalation path to escape the QA group's mandate.
Everywhere I've been save a military shop, the political lip service is paid, but everyone by default works on getting an exec waiver on QA pushback rather than actually addressing fundamental Quality issues.
So while the advertisement in question is technically true, the way it shakes out in reality is you either have Quality valued as a political factor by those at the top, or your entire org is built like the Titanic with watertight compartments (effective Quality Controls) only up to C deck.
At that point it just takes one good iceberg of a client/feature/bad product (iceberg)... And we all know how that goes.
That was not an article. It was an advertisement. Logic of advertising is distinct from normal everyday logic.
GP is making a point based on experience that maps well to my experience. Your entire team is committed to quality, and this includes stakeholders which express their commitment by treating Q/A as a first-class element of a product development process. Ideal setup imho requires a somewhat adversarial -- think Red Queen in genetic algos -- relationship between devs and q/a; and that the Q/A team and product team do -not- have the same manager.
Treat Q/A as 'internal affairs' in a police department. A fundamental necessity as developers also have a 'code of silence' regarding software misdeeds.
tldr;/ remember: even a lousy underwear gets to be inspected by Q/A.
Personally I've lost count of the number of no-code QA tools over the past decades I've seen that fail to deliver on their promise of painless QA automation.
