> developers won’t have to wait... can catch bugs earlier [in hours or minutes] That's what unit tests and mutation testing can help with, which should already

> developers won’t have to wait... can catch bugs earlier [in hours or minutes] That's what unit tests and mutation testing can help with, which should already be a part of the practice. Integration testing and performance/load testing could take longer, regardless if QA or devs do it. > shift testing to the “Plan & Design stage” Kind of wishful thinking. Having a separate QA as a different person has its advantages. Unless all or most bugs are reported by the developers, the economic reasons fall to either QA-reported--and here through deliberate, systematic breakage attempts or exploratory testing, employing years of accumulated domain knowledge and a nose for boundary conditions--or user-reported, which has its own risks with regards to satisfaction or repeat business. While such a team may exist, "let's talk about all the ways things could fail" is sadly not part of design talk. It seems like most of the time it's estimate, discuss some possible blockers, and get to coding ASAP. And, to be fair, sometimes we don't know until we're in tactical programming mode; coding and thinking it through become one and the same.