4 ms·

>I've always thought that the engineers in QC should be just as skilled and qualified as the ones building the product. I agree, but then they need to be equal

>I've always thought that the engineers in QC should be just as skilled and qualified as the ones building the product. I agree, but then they need to be equally well payed... and I don't think it is possible to find a manager willing to pay them as much

ponker 6y ago
Microsoft used to do it.
runawaybottle 6y ago
It’s probably a matter of how Important your application actually is. If it’s dealing with critical numbers or features that have a real cost when it breaks, then the investment into good testing pays for itself.
gav 6y ago
I think this is important and requires a big shift in how most organizations think of QA. A lot of QA being done is very mechanical and and done by junior staff offshore to keep the cost as low as possible. This causes the value to be low too, for example, the QA team for a F100 company I worked with would meticulously test against specs and file bugs such as "the error message is misaligned on page XYZ". Which was true, but they missed that the error message didn't make any sense at all. Improved automated testing has the opportunity to free up people to move from Quality Assurance (preventing defects) to being the voice of the user and ensuring quality products. This shift needs a completely different skill set and mindset, but equally it needs organizations to rethink both the cost of software engineering and the value it creates.
ChrisMarshallNY 6y ago
I worked for a Japanese company that was renowned for Quality (with a capital "Q"). In the US, having "Quality" in your title often means that you are in a dead-end job. In that company, it meant that you were an elite, and that you had considerable power over Engineering. It also meant that you were a completely anal-retentive S.O.B. They had spreadsheets with 3,000 rows (each row was a test -usually "monkey" test). If even one of those rows got a red "X," the whole shooting match would come to a screeching halt, with heads rolling around like foozballs. It also meant that they double-checked every bug report six ways to Sunday. If they reported a bug, It. Was. A. Bug. No ifs, ands, or buts. If you questioned it, they would get quite huffy; which was not a good thing (see "power," above). Management kept the QC organization quite separate from Engineering, and they often had an adversarial relationship; which was sometimes encouraged. This led to engineering departments having some very large testing teams; often outnumbering the engineers. The engineering departments would be penalized for bugs found by the official QC organization, so having large in-house testing teams was worth it. Their QC doesn't work especially well for software. They would get frowny faces, when I'd suggest automated testing, or process quality best practices. Quality was always treated separately from construction. I could never quite agree with that, but it also meant that I was "on my own," if I wanted to try using modern quality engineering techniques. Their [hardware] products are damn good, though. What many companies would consider minor quality issues are treated like Extinction-Level Events, at that company. They've been doing it for 100 years, so it's difficult to argue with them.
- redis_mlc 6y ago
  > The engineering departments would be penalized for bugs found by the official QC organization, so having large in-house testing teams was worth it. Some more details about that behavior are: In Japan, employees start with a zero score, then for each mistake lose a point. So they will analyze/block anything that could potentially cause a demerit. Obviously that's the polar opposite of "move fast and break things." Regarding the "3,000 line spreadsheet", yup, that's normal there and part of why their meetings often run to midnight. Gotta check and double-check every row before moving on to the next one. :) If you want to learn more about these cultural differences, read patio11's excellent posts about working in Japan.
  - ChrisMarshallNY 6y ago
    > their meetings often run to midnight. I still have PTSD from that. Nothing quite like a 14-hour flight, massive jet lag, and an all-day (and all-night) meeting in a packed, cramped, overheated conference room.
- yongjik 6y ago
  Totally unrelated, but your anecdote reminds me of Japan's WW2-era history - the animosity between the Imperial Army and Navy was so bad that the army built their own submarines.
  - redis_mlc 6y ago
    I study WW2. To expand on that: - Correct. Before the Doolittle Raid, they weren't cooperating with each other. Things totally changed after Tokyo was bombed. - One of the reasons for the Pearl Harbor bombing was because the Japanese navy had nothing to do, while the army was engaged in China. But had the navy and army been coordinated, they could have occupied Hawaii. - before Guadalcanal, the US Navy and Marines weren't very coordinated. After the Marines were abandoned there without half of their equipment and supplies, a protocol was developed that improved communications. Until today, the Air Force and Army fight over who can operate aircraft on behalf of the Army.

ponker 6y ago

Microsoft used to do it.

runawaybottle 6y ago

It’s probably a matter of how Important your application actually is. If it’s dealing with critical numbers or features that have a real cost when it breaks, then the investment into good testing pays for itself.

gav 6y ago

I think this is important and requires a big shift in how most organizations think of QA. A lot of QA being done is very mechanical and and done by junior staff offshore to keep the cost as low as possible. This causes the value to be low too, for example, the QA team for a F100 company I worked with would meticulously test against specs and file bugs such as "the error message is misaligned on page XYZ". Which was true, but they missed that the error message didn't make any sense at all. Improved automated testing has the opportunity to free up people to move from Quality Assurance (preventing defects) to being the voice of the user and ensuring quality products. This shift needs a completely different skill set and mindset, but equally it needs organizations to rethink both the cost of software engineering and the value it creates.

ChrisMarshallNY 6y ago

I worked for a Japanese company that was renowned for Quality (with a capital "Q"). In the US, having "Quality" in your title often means that you are in a dead-end job. In that company, it meant that you were an elite, and that you had considerable power over Engineering. It also meant that you were a completely anal-retentive S.O.B. They had spreadsheets with 3,000 rows (each row was a test -usually "monkey" test). If even one of those rows got a red "X," the whole shooting match would come to a screeching halt, with heads rolling around like foozballs. It also meant that they double-checked every bug report six ways to Sunday. If they reported a bug, It. Was. A. Bug. No ifs, ands, or buts. If you questioned it, they would get quite huffy; which was not a good thing (see "power," above). Management kept the QC organization quite separate from Engineering, and they often had an adversarial relationship; which was sometimes encouraged. This led to engineering departments having some very large testing teams; often outnumbering the engineers. The engineering departments would be penalized for bugs found by the official QC organization, so having large in-house testing teams was worth it. Their QC doesn't work especially well for software. They would get frowny faces, when I'd suggest automated testing, or process quality best practices. Quality was always treated separately from construction. I could never quite agree with that, but it also meant that I was "on my own," if I wanted to try using modern quality engineering techniques. Their [hardware] products are damn good, though. What many companies would consider minor quality issues are treated like Extinction-Level Events, at that company. They've been doing it for 100 years, so it's difficult to argue with them.

redis_mlc 6y ago
> The engineering departments would be penalized for bugs found by the official QC organization, so having large in-house testing teams was worth it. Some more details about that behavior are: In Japan, employees start with a zero score, then for each mistake lose a point. So they will analyze/block anything that could potentially cause a demerit. Obviously that's the polar opposite of "move fast and break things." Regarding the "3,000 line spreadsheet", yup, that's normal there and part of why their meetings often run to midnight. Gotta check and double-check every row before moving on to the next one. :) If you want to learn more about these cultural differences, read patio11's excellent posts about working in Japan.
- ChrisMarshallNY 6y ago
  > their meetings often run to midnight. I still have PTSD from that. Nothing quite like a 14-hour flight, massive jet lag, and an all-day (and all-night) meeting in a packed, cramped, overheated conference room.
yongjik 6y ago
Totally unrelated, but your anecdote reminds me of Japan's WW2-era history - the animosity between the Imperial Army and Navy was so bad that the army built their own submarines.
- redis_mlc 6y ago
  I study WW2. To expand on that: - Correct. Before the Doolittle Raid, they weren't cooperating with each other. Things totally changed after Tokyo was bombed. - One of the reasons for the Pearl Harbor bombing was because the Japanese navy had nothing to do, while the army was engaged in China. But had the navy and army been coordinated, they could have occupied Hawaii. - before Guadalcanal, the US Navy and Marines weren't very coordinated. After the Marines were abandoned there without half of their equipment and supplies, a protocol was developed that improved communications. Until today, the Air Force and Army fight over who can operate aircraft on behalf of the Army.