Comment by com2kid
17 hours ago
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.
The best places I've worked were places where QA reported up an entirely different leadership chain than engineering, and where they got their own VP with equal power as the engineering VP, and their own seat at the same decision-making table.
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.