Functional vs. Regression Testing – Know The Difference
By: Matt Angerer
Functional testing ensures that all aspects of a software program are working correctly and in accordance with the project’s requirements. For example, the software may have a series of input fields and a button that, when clicked, should save the input to a database. During functional testing, the tester will try entering either valid or invalid input (or both) and clicking the button to see what happens. If all input is in the correct format as per the data type requirements, then the database should contain (or at least update) the new data that was just entered. If any of the input fields were formatted incorrectly (e.g., entering numbers in a field that asks for a person’s name), the software should prompt the user to make the necessary changes.
After the software has successfully passed the initial functional testing phase, it’s both possible and likely that the software will undergo modifications over time. As more feedback is received from end users, certain features may be added, removed, or enhanced. Making such changes may have unintended consequences with regard to the software’s existing functionality. The primary reason most organizations can’t properly define their regression suite is because of a lack of traceability from the originating requirements, to the functional requirements, to the technical requirements, to the test cases.
Change Requests
As changes occur to a software system, organizations often submit what is referred to as “Change Requests” or “Enhancement Requests.” These are basically order tickets for customization and code changes to the existing software. A Business Analyst or Subject Matter Expert typically picks up this “order ticket” and identifies the original Functional Design that needs to be altered as a result. It’s then the Developer’s responsibility to reflect those changes into both the Technical Design and Software Code and Configuration. Herein is where a fundamental problem arises.
If traceability does not exist down to the regression test level, it’s difficult to understand what set of regression tests should be executed. You could go with the philosophy of 100% test coverage for every regression testing cycle, but that’s not always feasible with limited time and resources. Laser focusing your testing efforts is achieved when you can pinpoint how a change in one part of your system could potentially impact downstream requirements.
Regression Testing
Any problem that arises after the system has been changed is referred to as software regression. Changes in software, hardware, network configuration or even user input (such as a different data types than what was previously used) may be responsible for regression. Other common causes of software regression are incorrect or incomplete bug fixes, incorrect version control, and failing to update code according to component changes.
There are two types of regression: functional and non-functional. In functional regression, there is a loss of functionality. In other words, when one aspect of the software is changed, some other aspect stops working. In non-functional regression, the software’s functionality works as intended, but the system might now be suffering from performance or security issues.
The process of identifying undesirable behavior after changes to the system have been made is called regression testing. Ideally, regression testing should be performed any time there is a system change. Because regression is possible only in areas that have changed, one can save time by selecting only those test cases that cover the affected components of the system. Depending on the nature of the regression, some tests might lend themselves to automation, which would save even more time.
Although functional and regression testing can be done in-house, sometimes it makes more sense to outsource it. We can offer a fresh set of eyes that may uncover critical issues with your application’s functionality, performance, or security. Contact us to learn how we can assist you with your QA needs.
