QA is always the last place you look
Performing QA is as much a part of the software development process as writing code. The fact that it tends to appear as a step at the end of the development cycle does not make it less important or significant to the success of a product in an enterprise environment. The title comes from the phrase "it's always the last place you look" because you stop looking for things once you find them. QA, for most organizations, is the last step before deployment, which means it often gets short-changed. This little scenario offers a glimpse of one way that things can break down. And just to be contrary, this ISN'T going to be about Agile/Scrum/XP processes! We'll keep it old-school this time around.
As a starting point, let's take a look at the traditional waterfall model of software development. Suppose all business requirements were generated in the complete absence of any technologists. Let's say that these pie-in-the-sky requirements, after careful debate and collaboration on the business side, are handed off to the programmers to implement. For any non-trivial project, there will definitely be some requirements which would be impossible to satisfy (for either technical or financial reasons). What happens when the programmers try to estimate the development time and then actually attempt to build the product? If they're any good, they'll have the integrity to immediately go back to the business to discuss the issues and figure out what the scope really looks like.
The process taken to its extreme requires rework, so costs to develop new features are higher, the entire process is delayed, manpower is wasted, morale is impaired, etc.
It seems to me that the rules apply just as well to QA as it does to programming. Following this same line of thought, once coding is done and the product is handed over to the QA team, there are going to be aspects which are impossible to test (for either technical or financial reasons). Only this time the cost penalties are even higher, as the rework goes back to the programmers AND back to the business.
Here's where a hasty decision is made far too often. One option is to have the conversations, change the product scope, re-implement some aspects of the code, and then perform the QA functions as planned. Instead, the far more convenient (and taken) option is to declare that this requirement simply "is not testable" and move on. This shows such a lack of respect to the members of the QA team. The programmers get the privilege (and responsibility) to reject and negotiate requirements, but the only option for QA is to un-gracefully bow out all together.
Let's try running this scenario again, only this time we get a programmer and a QA person to sit in on the requirements gathering. That means it's far less likely to need to rework later for issues with implementation and also with QA. Their voices can be heard while the scope and understanding of the system are being formed, rather than cemented in a pile of documents. Rework is reduced (I'm not ambitious enough to say eliminated) which promotes shorter, more predictable timelines and reduced budgets.
While the business is often concerned with the cost of delivery, often the greater emphasis is on consistency and adherence to a timeline. Failing to have programmers and QA involved early in the process introduces variability in delays. And often as a response to failures to meet milestones on time, the last steps are often rushed or ignored completely if deemed unnecessary. This path is well-worn, with an abundance of defunct projects cast on either side.