I used to work at a company that addressed testing with a three-pronged strategy: 1) when estimating, dev tests are part of the strategy (and, ideally, stories

I used to work at a company that addressed testing with a three-pronged strategy: 1) when estimating, dev tests are part of the strategy (and, ideally, stories are written with enough detail to make testing strategies clear). Sometimes we review the ticket with QA to ensure that we both understand what's being asked for and what needs to be taken into account. Most tests at this point would include unit tests and functional tests. 2) Once a task is done, the story is reviewed with someone from QA to ensure it works. They suggest a couple of things to try that may require us to make improvements. The goal is to catch 80% of the issues at this point with 20% of the effort, and the pair-testing does a great job of flushing out issues. Here the focus is on functional tests and exploratory tests. 3) The QA team runs their own sprints testing the dev team's previous sprint's work. This is mostly performance and integration tests, but sometimes includes functional testing. I thought the process was good because we were able to measure our software quality and address it quickly. That said, it feels somewhat cumbersome. This isn't an easy problem to tackle.