We are working in agile methodology and one sprint contains only 10 days. In that time we need to develop the functionality and we need to test the application.
How is it possible to do regression testing manually in the sprints?
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.Sign up to join this community
I'd start by looking at the answers to this question.
If automated testing is simply not possible (it happens - I live there despite my attempts to get some kind of automated regression going. Being the only tester makes the effort to automate somewhere between challenging and impossible), I'd suggest something like this:
Nothing fancy, just to cover your basics
Do code reviews, understand what changed and how in order to optimize your tests. The test everything mentality will not work.
Between tasks being developed you will occasionally have some down time. Regression during this.
Ensure that you have plenty of test data for your scenarios and that there is an easy/efficient way to create this data.
Communicate with the team which areas you are focusing your efforts on. Often times scenarios can not be covered and areas can not be tested. It happens. Break the application down into multiple smaller pieces and then determine a priority level on each piece. If there is no direct impacts to either piece, you'd want to do far more testing in an area that is consistently used than an area that is seldom used.
Don't Repeat Yourself.
This is a common development principle that can roll over into the Agile QA world. Knowing where code is being reused and avoiding massive amounts of tests against identical code.
I work in an agile team with development cycles of ten business days as well. In my experience, this context does not make it possible to do a full regression testing after each sprint.
The strategy we've been using is:
Have three, four, five, or N sprints testing all the new functionality and the bug fixes.
Each sprint might have a partial regression test covering the modules affected during the sprint.
Then make a full regression test to the project. While we are doing the regression testing, developers use that time to increase unit test coverage and things like that.
Additionally, there are some practices that will help your team monitor the effect of new changes on the old code:
Automated Unit Testing: This is extremely important because it allows your team to quickly find defects after coding
Continuos Integration: This plus your automated Unit Tests will enable your team to detect side effects of the new code as soon as a commit is done
Microservices architecture: A microservices type architecture protects your application from side effects of code changes because each module works independently. Then, code changes do not affect other modules.
Quick answer: its not possible to do it manually, because regression suite increases with each new implemented functionality.
I suggest one of the options:
1) Automated UI: write automated test for each new functional Story in the Sprint.
2) Strengthening Sprints: Have normal Sprints (where development and testing is done), and one or two strengthening sprints before final release (where full regression testing is done).
3) Split sprint between DEV and QA days: e.g. first 7 days are for development and last 3 days are for stabilization, when QA executed reduced set of test cases.
Some of the ways to select regression suite is by: risk (functionality that affects most Users), modules that were modified in the sprint etc.