We are using Scrum framework in our project. However, the context is such that we cannot afford to release the product without massive regression testing. I know think what would be the best way to incorporate that into our Sprint. I can think of two options so far:
An extensive period of regression testing is something you should try to avoid at all cost when you want to practice Scrum. Not fully testing your software during or at the end of each sprint breaks one of the most important rules of Scrum, namely that the increment you deliver at the end of each sprint must be potentially releasable. It must be "done".
You may need to invest quite heavily in test automation and deployment automation to get to that point, but that is the best way to incorporate your regression tests into the framework. Try to make the effort of testing as low as possible. Deploy often and test at a high frequency.
If you're not there yet, try to invest a substantial amount of your sprint capacity to reduce the time needed for regression testing. You're in a situation with a high technical debt (in testing) and need to get out of that situation.
You might also be able to employ tools that detect coding issues automatically and train your development staff to improve their knowledge in both the domain and the technology.
Dive deep into techniques like:
To continuously improve the quality of your product, your process and your people.
These solutions can temporarily help you, but are not meant to be the definite cure to your problem.
Hardening sprint (shudders) In the mean time, there are some practices that may work for you in the short run. A dedicated sprint is what is often called a "hardening" sprint. Many teams use this
Buffer Alternatively, have a a separate team do continuous regression testing and make sure that bugs are placed on the product backlog, just like every other work. The development team could keep a buffer in their sprint plan to resolve issues coming out of previous sprints. This is not optimal, as the work that was deemed "done" before turns out to have bugs after all. Make sure the development team already does the bulk of the testing and that only the regression work that won't be possible during the sprint is done by the other team. The development team has the primary responsibility for the quality of the product.
Spend time to find out how these bugs made it into the product and try to find ways to prevent this. Do you need to work closer to your end-users during the sprint so you can catch these items earlier?Do you need to do more automation to find these every night after you check in? Is there an automated check that you can enable in your development environment that could detect these (technical) issues in a Continuous Integration build? In every next sprint spend some time to make sure you plug one of the holes in your process and tools to reduce the chance of these things happening.