Regression Testing

A software regression is any defect that occurs when a fix/change is added to the code. And regression testing ensures that the new change hasn’t affected the rest of the code in the application anywhere. Regression can happen in different ways :

 When new functionality is added: When developers introduce new code, it can cause compatibility problems with the existing code. Regression testing is done to find possible issues.

  • A functionality revision: When developers revise the existing functionality and delete or change some features, regression testing checks whether the feature was removed/edited with no damage to the rest of the code.
  • Integration: Here, regression testing assures that the software product performs perfectly after integration with another product.
  • Bug fixing: New bugs may generate due to another bug fixing sometimes. It requires changing the source code, which in turn calls needs re-testing and regression testing.

Methods of Regression Testing

Manual regression: This is the basic method for regression testing for every product, regardless of the methodology (waterfall, Agile etc). Manual always precedes automation, in some cases being even more efficient than the latter. For example, it is impossible to write a test script for testing areas adjacent to the part of the code that was changed.

Manual regression testing is efficient in the early stages of the delivery process. But the main problem is that it is time and effort consuming. For complex products, running a regression test suite over and again hinders a test engineer’s concentration and his or her performance. Thus, in such cases, teams prefer to switch to automation.

Automated regression:

Automated regression testing is done for medium and large projects at the stage when the project is stable, i.e. no critical changes in business logic and UI are expected. With thorough test planning, automation reduces the efforts a testing team spends on tedious and repeatable tasks and spares them time for testing, such as exploratory testing and UX testing.

However, today teams often start test automation at the early stages. It works well for an Agile environment where teams should deploy a product at least weekly and have no time for warming-up manual regression testing. Communicating with the whole team and studying the use case document, testers can understand the stakeholders’ needs, the product business logic and expected results for testing. The main task here in early automation is choosing the testing framework. It should provide easy scripting and low-cost test maintenance. The created infrastructure can be reused for future products, hence accelerating test automation.