Comment by ethbr1
21 hours ago
> Two QA per dev??
QA is a lot cheaper than dev. If your goal is to make quality software* on a fixed budget, you want to be QA-heavy.
* Note: the OS definition of "quality software" drastically differs from your average app.
> QA is a lot cheaper than dev.
QA is definitely one of those "you get what you pay for". A dev just bangs out code on what is assumed "happy path" which means the user uses it as the dev expects. QA has to some how think of all the inane ways that a user will actually try using the thing knowing that not all users are technically savvy at all. They are actively trying to break things not just feed in clean data to produce expected outputs. Let's face it, that's exactly what devs do when they "test". They are specifically trying to get unexpected outputs to see how things behave. At least, good QA teams do.
I worked with a QA person who I actively told anyone that listened that the specific QA person deserved a higher salary than I did as the dev. They caught some crazy situations where product was much better after fixing.
> QA has to some how think of all the inane ways that a user will actually try using the thing knowing that not all users are technically savvy at all.
The classical joke is: (this variant from Brenan Keller[0])
A QA engineer walks into a bar.
- Orders a beer.
- Orders 0 beers.
- Orders 99999999999 beers.
- Orders a lizard.
- Orders -1 beers.
- Orders a ueicbksjdhd.
First real customer walks in and asks where the bathroom is.
The bar bursts into flames, killing everyone.
[0] https://xcancel.com/brenankeller/status/1068615953989087232?...
That's just a bad dev. Good devs don't think of just the happy path. My experience of QA as a quality focused dev has not been good.
The purpose of QA is to identify the unhappy paths that the good devs missed, not to compensate for bad devs.
I feel that not only should QA staff outnumber developers, but QA staff should have access to development time to design and improve QA tooling.
If you're doing an OS right, the quality is the product. I think MacOS prior to the launch of the iPhone would be the gold standard the kind of product design I'm talking about. At that time they were running circles around Windows XP/7 in terms of new features. They were actually selling the new OSes and folks were happy to pay for each roughly annual upgrade. Often the same hardware got faster with the newer OS.
Lately Microsoft and Apple are racing to the bottom, it seems.
The irony here is that the market is willing to pay for quality.
I don't have time to deal with phone issues-it should just work so I can get on with my day.
Hearing that Apple were dedicating time to stop features and go after stability is exactly what I want to hear.
The saddest here is "were". iOS 26 is every day showing us that quality left Apple few years ago.
1 reply →
Important to note MS used to have 2 types of QA:
1. SDETs (software design engineer in test) - same pay scale and hiring requirements as SDEs, they did mostly automated testing and wrote automated test harnesses.
2. STEs (software test engineer) - lower pay scale, manual testing, often vendors. MS used to have lots of STE ftes but they fired most of them in the early 2000s (before I joined in 2007).
An ideal ratio of SDETs to SDEs was 1 to 1, but then SDET teams would have STE vendors doing grunt work.
Having STEs as full time employees benefited MS greatly. They knew products from the end user and UI/UX perspective inside and out in ways even the SDETs didn't.
UI/UX quality in MS products dipped noticeably after the STE role was eliminated.
Imho, there are two key values that I've seen QA bring to software companies.
1. Deep user/product expertise. QA (and support) almost always knows more about how users (including expert users) actually use the product than dev.
2. Isolation of quality from dev leadership politics. It should be unsurprising that asking an org to measure and report the quality of its own work is fraught with peril. Even assuming good intentions, having the same person who has been developing and staring at a feature for months test it risks incomplete testing: devs have no way to forget all the insider things they know about a feature.
1 reply →
2 people doing QA per dev seems insane even if it’s a lot cheaper. M$ is hardly know for being obsessed with quality, they’d rather have 2 sales per dev (sales is even cheaper, basically pays for itself)
It's a lot easier to write code than to make sure it doesn't break something you didn't account for.
Microsoft's quality control used to be: release a buggy new OS then forge a solid next release.
Going backwards in stability is out of character.
I've never known M$ to be lacking on the sales front, personally!