Think twice before hiring QA for your startup(rainforestqa.com)
rainforestqa.com
Think twice before hiring QA for your startup
https://www.rainforestqa.com/blog/hiring-qa
9 comments
Following the logic in the article: it's not actually a good outcome for the business when "Your QA people are the only ones charged with being an organizational conscience on the behalf of your users." To your earlier point, quality is something the entire team has to commit to.
Mmmhmmm.
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.
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.
> Following the logic in the article
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.
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.
>tldr;/ remember: even a lousy underwear gets to be inspected by Q/A.
And remember, if your QA group are dropping like flies because they can't in good conscience condone signing off on the output of a lousy underwear assembly line, that too is strong signal.
And remember, if your QA group are dropping like flies because they can't in good conscience condone signing off on the output of a lousy underwear assembly line, that too is strong signal.
That speed vs "fixing it" after an embarrassment trade-off is a hard one - def seen many folks hit that. Avoiding being / having to be reactionary in the first place is probably the smartest, if you can pre-plan!
For sure. For me, the best (worst) sign of 'not proactive enough' re: quality is too many embarrassments and/or hotfixes happening.
100%; they're related. It's easy to fall into the trap of "move fast and break things", then over react and make shipping slow, which sucks for everyone involved. Getting the balance right when you're early is hard, as tooling choices stick around, and "you don't have time". Def worth getting right.
Nothing that's said there is wrong per se but the writing is biased toward trying to sell the reader on buying their QA products and outsourcing. Which is fine, it's their corporate blog, but just take it with a grain of salt.
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.
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.
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.