3 ms·

Devs doing QA worked fine for us. You need to have a team that actually cares about the product, and you need figurehead devs - not necessarily seniors or team

Devs doing QA worked fine for us. You need to have a team that actually cares about the product, and you need figurehead devs - not necessarily seniors or team leads, but charismatic people others will fall into line with - who model the behaviours you want. The problem with almost anything else is that it increases the number of hand-offs between groups of differently-aligned people on the route to production. If you're aiming at multiple deployments per day, with sub-hour commit-to-prod times, the latency in those hand-offs adds up way too fast.

failwhaleshark 5y ago
Yep. Fire the aholes and the egos, and keep the messianic figures who go-give and get shit done.
jokethrowaway 5y ago
My main problem with devs doing QA is that QA is huge, knowing the entire product is hard. In my case, devs were just testing what they changed and never noticed something horribly broken somewhere else. I think all devs should test that what they built works in production (you don't need QA for that), you need QA to keep everything else tested and working.
- regularfry 5y ago
  > devs were just testing what they changed and never noticed something horribly broken somewhere else. There's your problem. If they broke it but didn't test what they broke, then they changed it but didn't realise they had. "Horribly broken elsewhere" sounds like the sort of thing that should show up in an automated test, no? If the problem is "we don't have a good enough automated test suite and our architecture doesn't limit the blast radius of changes" then I can see how throwing QA headcount at it might look tempting.
notmyfuture 5y ago
A person doing manual testing, which is a gate to deployment would certainly be hard to make work for deploys as fast as you're targeting. It may still be valuable to have someone separate to the devs testing your product (in production, not as a gate to release) looking for things your automated testing, customer feedback or metrics may have missed. Whether this would be valuable is really context-dependent.

failwhaleshark 5y ago

Yep. Fire the aholes and the egos, and keep the messianic figures who go-give and get shit done.

jokethrowaway 5y ago

My main problem with devs doing QA is that QA is huge, knowing the entire product is hard. In my case, devs were just testing what they changed and never noticed something horribly broken somewhere else. I think all devs should test that what they built works in production (you don't need QA for that), you need QA to keep everything else tested and working.

regularfry 5y ago
> devs were just testing what they changed and never noticed something horribly broken somewhere else. There's your problem. If they broke it but didn't test what they broke, then they changed it but didn't realise they had. "Horribly broken elsewhere" sounds like the sort of thing that should show up in an automated test, no? If the problem is "we don't have a good enough automated test suite and our architecture doesn't limit the blast radius of changes" then I can see how throwing QA headcount at it might look tempting.

notmyfuture 5y ago

A person doing manual testing, which is a gate to deployment would certainly be hard to make work for deploys as fast as you're targeting. It may still be valuable to have someone separate to the devs testing your product (in production, not as a gate to release) looking for things your automated testing, customer feedback or metrics may have missed. Whether this would be valuable is really context-dependent.