Notes of the session Where is QA gone?

Most of us are not able to release the product at end of sprint. We miss regression testing. This is more true with large and complex products that are made of Millions of lines of code and that are composed of a large amount of features interacting with each-other. Multiple teams interact and change areas of the code and team members may not have the complete product view.
Even though we have DoD in place that say that "if QA is not done", the team is not done. We cannot conceive that the team be able to do all the testing, including regression, performance, negative testing, scalability... on a wide variety of platforms and all in one sprint. So, how is this addressed in Scrum "ideal" world? Or this cannot be realisticaly addressed with real life product?
When you have inheritated, a large code base (4Mio lines) dating from the nighties, and you want to introduce scrum, you cannot immediately claim you have 100% automation. Even getting 10 % automation is a significant effort. But is not sufficient. How would you address this in-progress situation? This may last years...
We are seeing that the people that had previously tester roles are the ones that write the automation test srcipts.
Testing with offshore teams is difficult. How can this be done?
Most of us implement scrum for the development with a mix of tester's and developer's background people. But we cannot release the product. Regression tests still unveal defects that were not found during the sprints. We call this the "Caboose" of the project. The problem is that we do not know the size of this caboose, and we do not know its composition, so we have very few information to offer to the PO for him to make a call regarding the release date. Most often, this date is fixed.
We see Unit tests, automation and TDD may be things we want to introduce to an organization, but these take time and it is also about changing people and culture.
SCrum is cool. But we have a lot of information about being scrum... we miss information about going scrum from Waterfall. Especially for the QA domain witthout interrupting the release lifecycle.
Should we write " regression " PBI for the regression effort? Should we have our developers execute regression tests? They will not buy that and it may not be the best usage of their time, they will argue.
Continous integration Helps! Good way to get started.
We have seen something working: QA-oriented people writing the test cases & automation code while dev-oriented people fo the code during a sprint.
Working with new code or a code base that evolves over years and that was not agile / scrum developped are two diffirent things. Building on small team / large teans aksi makes a difference.
IMPORTANT note: DO NOT put QA out of the sprint team. Otherwize the quality goes down,
CONCLUSION: Few of us are able to release after one sprint. Especially the ones dealing with large and complex products. All of us see value in having qa activities in the sprint that range from test case edition, unit test, test automation to test case execution. This said, ALL of us are doing some form of regression testing / bug fixing at the end of the project, prior to the release, we call this the caboose. This phase is done by a separated set of people (offshore or not) or by the team members themselves running the test cases. We see that there is benefit in Unit Testing, continuous build integration, test case authoring and execution in the sprint and most of it Automated testing. As we are called scrum " But " or are facing the sarcastic laught of Jeff, we would like to know more how scrum deals with that. Saying, ah ah ah ah ah this is not scrum is ridiculous. Are we not scrum or is scrum not adapted to those real-life examples? We definitely want to ear and read more on this.