The "Mitigating Measures" section makes clear that the silent assumption basically is "you're writing an online service" (or an app that can afford quick update cycles).

In other fields, I have very different experiences with having dedicated QA, and working with QA can be a very collaborative process, especially where QA has domain expertise the developers do not have to the same degree. Setting them up to be in conflict is at least partially an organizational failure. (is codereview bad because it pits developers against other developers?) Along similar lines, test automation can be a tool that makes both jobs easier: it shortens feedback loops for developers, and allows QA to concentrate on things that are not easily covered by automation.