Optimizing Regression Testing in Agile Development

Editor’s note: If in your Agile project, you find yourself torn between ensuring regression testing coverage and sticking to release deadlines, apply ScienceSoft's 34-year experience in software testing to solve your regression testing dilemma. The article below, describes ScienceSoft's approach to Agile regression testing.

Regression testing often becomes a pain point for an Agile project manager, as it presents two major challenges:

1. Increased time and efforts. Regression testing may take up a lot of time, especially in large projects. Sometimes, teams have to spend an entire sprint on regression, which is hardly acceptable. And increased time and efforts mean increased costs.
2. Lack of test engineers’ concentration. Running same test cases again and again for a long time results in the lack of concentration. This can lead to bugs sneaking into production, which also increases overall project costs.

Providing software testing services since 1989, ScienceSoft has worked out and successfully implemented the strategies to solve these problems. Let’s explore some of them.

Regression testing in Agile: How to optimize?

To streamline regression testing in Agile development, ScienceSoft testing teams leverage the following methods: combining iteration and full regression testing, prioritizing tests according to a risk-based or a collaborative approach, and automating regression testing for increased velocity required by Agile.

Let’s have a closer look at the pros and cons of each method.

Two-level approach

Following this approach, ScienceSoft testing teams break regression testing into two cycles:

1. Iteration regression. The team performs iteration regression at the end of each sprint. Iteration regression specifically focuses on features and changes made in the iteration and areas of the application that could have been affected.

2. Full regression. ScienceSoft's test engineers run full regression before a release to ensure that the application works as planned.

However, the two-level approach is not as simple as it seems. To be successful, this approach requires a seamless communication within the project team. ScienceSoft testing teams pay special attention to the communication with the developers to get a comprehensive view of what was done in the iteration and knowingly choose the regression testing type.

Test prioritization: Risk-based approach

Applying the risk-based approach to regression testing, ScienceSoft testing teams choose test cases covering the application areas affected by recent changes in the project and rank them according to the priority, which reduces testing time and efforts.

• High priority. In the majority of ScienceSoft's testing projects, these test cases comprise around 10% of the total number of regression test cases. They cover critical software functions, software aspects that are most important for its users, defect-prone aspects, and areas that underwent many changes.
• Medium priority. These regression test cases comprise about 30% of the total number of regression test cases and describe exceptional conditions (negative test cases, boundary value test cases, etc.). This priority mostly applies to the test cases that repeatedly detected bugs in previous software releases.

High and medium priority test cases are always included in the regression test suite to be run after a new iteration.

• Low priority. These test cases cover the remaining 60% of regression test cases and validate the rest of software functionality. ScienceSoft's test engineers use them in regression testing before a major release to ensure the complete test coverage.

Thus, assigning priorities helps reduce regression testing time and efforts in Agile projects with no damage to product quality. However, this approach may cause some problems, as a testing team is fully focused on their testing tasks and cannot grasp the picture of the entire project. Luckily, there is another strategy that fully correlates with Agile specifics.

Test prioritization: Collaborative approach

This approach allows all project team members to contribute their knowledge and unique perspective to regression testing. During an iteration, a project team works out a covering every change that was introduced during the iteration. Typically, ScienceSoft's testing teams arrange the cards according to what should be tested first. Other team members then suggest corrections to the proposed order. For instance, a developer understands that a recently added feature may influence critical functionality, which was not obvious for the testing team. When it’s time to run regression testing, our testing teams consult the board and assess time investments.

Though reasonable and convenient, prioritization approaches need caution, as they may lead to technical debt.

But how is it possible to optimize Agile regression testing and keep control over a technical debt? The answer is – to automate regression testing.

So, let's have a look at the third ScienceSoft's optimization strategy.

Regression testing automation

Through multiple Agile projects, ScienceSoft's regression testing automation has proved to be the best way to deal with most common challenges this testing type presents. For example, for one of our clients, we have opted for test automation to optimize regression testing of a vCIO solution. Automated regression testing helped us reduce the testing time and let test engineers focus on exploratory testing instead of running the same regression test cases again and again.

The right time is the first thing to consider when planning regression tests' automation. Manual testing efforts better fit the early project stages, when software undergoes changes in the UI, product flow or logic. ScienceSoft's test automation engineers introduce automated regression testing when the project has already reached some level of stability, and major changes have already been made. Besides, our manual test engineers typically verify automated regression results with quick smoke tests to identify false positives/negatives.

Another thing to mind is that automated regression test suite cannot stay valid during the entire project. In Agile, automated regression test suite should fully reflect the changes and updates in the application functionality. Therefore, ScienceSoft' test automation engineers review it after each major release, change or discard obsolete test cases.

Focus on communication

To further optimize agile regression testing, ScienceSoft's testing teams ensure seamless communication with other project team members:

• BAs to monitor the changes in requirements and assess them from the testing perspective.
• Developers to learn which changes they made during a particular iteration.
• PMs to update them on the current state of testing and avoid time crunches at the end of a project iteration.

Quality at speed with truly agile regression testing

Regression testing in Agile may seem a bitter pill: tedious but necessary to assure the software quality. If you struggle with adapting your regression testing to the needs of Agile, ScienceSoft is ready to support you with full-cycle software testing services.

Test my application

Start testing

Get Software Quality Ensured Within Strict Deadlines

ScienceSoft's testing teams can dive into your project at any SDLC stage to provide efficient KPIs-based manual and automated testing services.

Start testing