I do not believe in QA as a separate discipline (and a separate person) on a Scrum team. I know this is unpopular, or at least it has been at some of my larger clients, companies I have worked for. It definitely does not make me popular with QA professionals.

 I believe that separating the discipline of QA from development is an artifact of Waterfall thinking and acting. It has no place in Scrum because it sets up a mini-waterfall effect on a Scrum team which is hard to manage and defeats the purpose of Scrum at its best.

 What I believe QA should be is built in from the beginning, with TDD and unit tests, with automated testing (integration, browser compatibility, security, performance, monitoring etc.) and that this should be done by the developers doing the work so that they get direct feedback on their work from themselves and each other. They are the ones that should have a vested interest in whether they are going to be woken in the middle of the night with a production support issue. They are the ones who can most effectively blend the act of coding with the act of testing.

 This doesn’t mean we get rid of QA professionals but what it does mean is that their focus changes towards automation so that they can run alongside other developers as they work without the Waterfall effect, and that they also build up their coding/DevOps skillset so they can be more valuable to the cross-functional team then just writing and running test scripts.

Quality needs to be built in from the beginning, not thrown over the wall to someone else. It is a value that needs to be instilled in the product, not added after the fact. Do this right and your quality will go through the roof. It will never be perfect but will be as perfect as can be achieved.