> 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. 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 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.
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?...
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.
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.
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.
UI/UX quality in MS products dipped noticeably after the STE role was eliminated.
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.
When QA is subordinate to engineering, they become a mere rubber stamp.
A good question to ask when joining a software company is "Does QA have the power to block releases over the objection of engineering?" I have found companies who can answer YES to this put out much better products.
There was a real problem of QA becoming bloated and filled with less than qualified people. The really good engineered would transfers out to SDE orgs and so the senior ranks of QA tended to be either true believers are people who weren't good enough to move to SDE orgs.
Especially with QA outside of Microsoft at the time paying so much less, it was a wise long term career move to move to SDE as soon as possible.
Going backwards in stability is out of character.