In the old days, military/government contractors were the gods of management. They had huge development staffs, rigorous procedures, colossal budgets. Those where the people to watch. Everyone wanted those staffs, those projects, those budgets.
QA and Development were split. Development was owned by the contractor, and QA by the customer.
Sometimes the contractor had their own QA people to help assure that their product would pass the customer QA process.
The customer's QA was focused on proving that the contractor had not finished the project, and so they don't need to be paid yet.
The goal was to PREVENT COMPLETION of the contract and delivery of the code.
The contractor's developers and testers argued that they did indeed fulfill the terms of the contract and should be paid post-haste.
Of course it was important that the contractor/developers did not know what tests were going to be performed, else they would write code to pass those tests and get paid for doing the minimum.
The threat of not being paid for on-time completion was supposed to scare the contractor into making EVERY ASPECT of the code as perfect as possible, and supposed to make them sweat every small detail that might end up in a client-side test plan.
The next step is typical of cargo-cult behaviors in our industry; if we copy easily observable behaviors of successful people , we will be successful too!
I think the "separate, independent QA" practice has outgrown its useful context by several decades. Nowadays we want organizations to enable completion and delivery, not prevent it. We're not building software on contract for people who want to avoid paying us, we're partnering.
The new model breaks a lot of old, broken traditions. Good.