Different continuous delivery teams do it differently. I don't like having a dedicated QA team/department. QA is an effort, not a role.
The key part of continuous delivery is that the safest change to make to a stable system is the smallest change possible.
So instead of batching up lots and lots of stuff and throwing it over the wall to QA, you make one change, have humans and robots test it, and deploy that change. The mindset shifts from "features per release" to "releases per feature" so with truly friction-less automated deployments, you can release very small changes individually. You don't have to test everything in order to change anything.
As you may expect, multiple layers of test automation are necessary. Each change runs a gauntlet of different kinds of tests before release. A set of "safe to run in production" tests immediately after release. Rollbacks are trivial, but exceedingly rare.
Obviously, this only works in some contexts. If you're pressing things onto gold master DVDs and shipping them in boxes, the QA effort will be more traditional.
The key part of continuous delivery is that the safest change to make to a stable system is the smallest change possible.
So instead of batching up lots and lots of stuff and throwing it over the wall to QA, you make one change, have humans and robots test it, and deploy that change. The mindset shifts from "features per release" to "releases per feature" so with truly friction-less automated deployments, you can release very small changes individually. You don't have to test everything in order to change anything.
As you may expect, multiple layers of test automation are necessary. Each change runs a gauntlet of different kinds of tests before release. A set of "safe to run in production" tests immediately after release. Rollbacks are trivial, but exceedingly rare.
Obviously, this only works in some contexts. If you're pressing things onto gold master DVDs and shipping them in boxes, the QA effort will be more traditional.