4 ms·

Every org I've worked for that has had a dedicated QA team has had, by far, the shittiest quality of code and the most amount of bugs in the system/outages/issu

Every org I've worked for that has had a dedicated QA team has had, by far, the shittiest quality of code and the most amount of bugs in the system/outages/issues in production. I am not sure _why_ this is but I think it has something to do with the "Not my problem" mentality where engineers say "QA will figure out if this works or not" instead of "I'm responsible for figuring out of this works". It hasn't become a red flag for me _yet_ but it's definitely _a_ flag.

stevezsa8 6y ago
As a QA myself, every project I've worked on except maybe one... has had good shared ownership of quality. Maybe it's because we were embedded in the dev team. Sorry you didn't experience the same thing.
toast0 6y ago
Be that as it may, a team that would have shitty code with QA will likely have shittier code if you fire QA. Case Study: Windows 10. That said, an understaffed QA team can be really helpful. Not enough people means you can't ship garbage and expect QA to catch it; they'll catch many things, but not everything. Not enough people also encourages efficiency in testing --- test the most important stuff well, test the other things opportunistically. A QA team also can really help turn customer problem reports into actionable bug reports.
ZitchDog 6y ago
The red flag for me is when QA is considered a non-coding team, divorced from product. QA engineers should be very technical, and should be writing code or automating. A non-automated QA process kills the feedback loop of the product.
hmillison 6y ago
Agree with this, it's very important for engineers to own the quality and reliability of their own code. The team I was on that had embedded QA on each team had barely any unit tests because developers were used to relying on QA to catch bugs for them. When I've been on teams without formal QA teams, the team was focusing way more on having good automated test practices in place. This also applies from the SDET/SDE separation, which I see someone else in an adjacent thread mention. I've found a lot of value from taking ownership of both the code and the automated browser testing code. I found when those roles are separate, the browser tests end up breaking too often due to developers not being aware of how coupled they are to the current implementation. I also found when a dedicated team is writing browser tests, it becomes easy to go overboard with how much you test.

stevezsa8 6y ago

As a QA myself, every project I've worked on except maybe one... has had good shared ownership of quality. Maybe it's because we were embedded in the dev team. Sorry you didn't experience the same thing.

toast0 6y ago

Be that as it may, a team that would have shitty code with QA will likely have shittier code if you fire QA. Case Study: Windows 10. That said, an understaffed QA team can be really helpful. Not enough people means you can't ship garbage and expect QA to catch it; they'll catch many things, but not everything. Not enough people also encourages efficiency in testing --- test the most important stuff well, test the other things opportunistically. A QA team also can really help turn customer problem reports into actionable bug reports.

ZitchDog 6y ago

The red flag for me is when QA is considered a non-coding team, divorced from product. QA engineers should be very technical, and should be writing code or automating. A non-automated QA process kills the feedback loop of the product.

hmillison 6y ago

Agree with this, it's very important for engineers to own the quality and reliability of their own code. The team I was on that had embedded QA on each team had barely any unit tests because developers were used to relying on QA to catch bugs for them. When I've been on teams without formal QA teams, the team was focusing way more on having good automated test practices in place. This also applies from the SDET/SDE separation, which I see someone else in an adjacent thread mention. I've found a lot of value from taking ownership of both the code and the automated browser testing code. I found when those roles are separate, the browser tests end up breaking too often due to developers not being aware of how coupled they are to the current implementation. I also found when a dedicated team is writing browser tests, it becomes easy to go overboard with how much you test.