Retrofit testing, retesting, and regression testing are sometimes confusing terms for new business testers.
Selected definitions from external sources:
Wikipedia: Retrofitting refers to the addition of new technology or features to older systems.
Oxfords Dictionary: Retesting. Test (someone or something) again.
US National Institute of Standards and Technology: Regression Testing. Rerunning test cases which a program has previously executed correctly in order to detect errors spawned by changes or corrections made during software development and maintenance.
IEEE: Regression Testing. Selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still complies with its specified requirements.
Retrofit testing is carried to to test that a change in functionality is correctly implemented for existing entities. Retesting is carried out to verify the defect fix(es) by running the same test(s) that failed the first time, with the purpose of verifying that the defect fix has corrected the defect. Regression testing is carried out to check if the defect fix / fixes have not impacted any other functionality of the application that was working fine before applying the code changes.
Retrofit testing is more commonly carried out when you have an incremental project, or change requests. For example, if your project is rolling out a template solution and you’ve already gone live in the Americas, but during the discovery phase for Europe you determine that a change is required that will impact existing live processes, then your US branch will need to do retrofit testing to confirm that the change works for them.
Retesting is typically specific to defect fixes being released for the current build, and involves re-executing test cases that were failed earlier in the current test phase, and/or new tests to specifically test that an issue has been fixed, and targets the testing of an issue or specific functionality.
Regression testing involves executing test cases and/or scenarios that were passed in an earlier build i.e., functionality that was working prior to the transport release. Regression testing is more generic and may not target the specific area of any defect fix or code change, but is intended to ensure that a fix in one area has not adversely impacted any other areas – it’s testing to make sure things still work the way they did.
If the time available to test is tight, retesting and retrofit testing usually takes a higher priority over regression testing i.e., verify the known problem of the bug and fix first, find any new issues with changed functionality, and then regression test other parts of the application based on a risk assessment of the likelihood of the bug fix and changes affecting existing functionality. Depending on the size of your test team and their specialities, retrofit testing, retesting, and regression testing can be carried out in parallel.
Although retrofit testing, retesting, and regression testing have different objectives and priorities, they are all important and must be considered in every environment that a transport is imported into.