Is Full Regression Testing Required in Agile Development?

November 6, 2015 Appirio

By Neerav Patel


One of the most important features of Agile Development methodology is the client review/demo at the end of every sprint. The client, being the functional owner, suggests changes during the demo/sprint review that then have to be implemented in the existing development. But once the changes are made, it can be a tedious job to ensure that the application performs the required business functions.

The role of regression testing

This is where regression testing comes in — as a powerful test practice that is applied to an application during testing once the necessary changes are introduced. Regression testing is done to ensure that the intended functionality is working as expected once changes have been made.

The introduction and implementation of any change may have a negative impact on the system or data, an impact which could have a ripple effect if the rest of the system is affected. It is the responsibility of the quality control team to monitor the basic functionalities of the software system when new changes are added.

Without a doubt, full regression testing is a time-consuming process, so it is always a tricky question as to when and how much regression testing is required. Do we need to run a round of full regression testing every time? It depends on the complexity of the application. If the application is not complicated — does not have many dynamic modules/parts, does not involve many calculations, does not involves input from multiple sources — then full regression testing is not necessary. Remember, we are talking about full regression testing; in this case, we can run a quick round of smoke test cases pertaining to the application’s core functionality.

The necessity of full regression testing depends on the following factors:

  • How many parts of the application were modified.
  • If there were changes made to the stored procedures/triggers/workflow rules. (This drives the overall business logic.)
  • How many hours of development effort went into making the necessary changes.
  • How many — and to what degree of severity — functional issues were detected during the sprint? (The motive is to ensure that the existing functionality is not compromised.)
  • Do applications support old browser versions? Sometimes heavily customized pages go through extensive changes so as to maintain compatibility with the required version of a browser. These changes often cause basic search button-like functions to stop working, simply because the required search UI page cannot load easily.
  • How long the project takes.

Scheduling a full round of regression testing in the middle of every sprint is a nice practice to safeguard the software from any unforeseen errors, so that the software works well even after introducing many changes. But if not, regression testing can be scheduled at the end of each sprint.

Regression testing is a core part of the QA lifecycle for long- and short-term projects — both which we can love or we can hate, but we cannot ignore.

Previous Article
Building Dynamic Stacking Bar Charts in Visualforce
Building Dynamic Stacking Bar Charts in Visualforce

By Pankaj Mehra Salesforce’s Stacked Bar Charts visualizes grouped data, segmented proportionally by a key ...

Next Article
Lightning Process Builder: How to Initiate the Approval Process
Lightning Process Builder: How to Initiate the Approval Process

By Rahul Agrawal Salesforce’s Spring 15 release launched a new feature called Lightning Process Builder. Pr...