Manual Regression Testing in Agile

Question

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?

Answer 1

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:

• Identify highest priority test cases - each sprint, prioritize all your test cases, and flag those with the highest priority. I'd use a combination of risk and steel thread to decide. These get added to your regression test suite and prioritized in context with the other tests there.
• Start the sprint with regression - as testers, we'll typically have little in the way of new work to test at the start of a sprint. In addition to using this time to plan the testing for the current sprint, use it to run regression test cases for previous sprints. If you're starting sprint 10, you would run regression test cases for sprints 1 - 8 (because there's no changes to sprint 9 code yet). In sprint 11 you run test cases for sprints 1 - 9. And so on.
• Prioritize aggressively - you're working to a timebox, so you can't do everything. If the work for the current sprint means you can only cover the ten highest priority regression test cases, then that's what you cover
• Document your regression - make sure that your part of each sprint review includes what you did not regression-test and why.
• Be sane - No matter what the application is, there will be parts of it that will receive near-continuous attention and use. If you pay attention to these areas while you are using them on your way to your actual test cases, you will effectively give them basic regression. It may not be ideal, but it can be enough.
• Treat your test suites as a backlog - and groom them aggressively. If a test case isn't relevant anymore, don't hesitate to retire it. If one needs updating, update it.
• Give your test cases execution time estimates - if you know about how long it takes to run each test case, you can use this in your test estimation and planning. Sadly, not all tooling supports this, so you may have to add the estimates to the title or body of your test case.
• Plan test cases as part of the sprint planning - Your regression test cases are as much a part of the sprint planning as any other activity. Build them into the sprint planning session if at all possible. If not, figure out beforehand how much time you're going to commit to regression testing, and lower your availability for the sprint accordingly.

Answer 2

• Automated Regression Suites

Nothing fancy, just to cover your basics

• Identify Areas of Risk

Do code reviews, understand what changed and how in order to optimize your tests. The test everything mentality will not work.

• Regression Early

Between tasks being developed you will occasionally have some down time. Regression during this.

• Easy access to data

Ensure that you have plenty of test data for your scenarios and that there is an easy/efficient way to create this data.

• Identify and Discuss Risks

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.

• DRY

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.

Answer 3

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.

Answer 4

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.