Regression Testing: What is it and How to Use it

It is a common practice that when a defect is fixed, two forms of testing are done on the fixed code. The first is confirmation testing to verify that the fix has fixed the defect and the second is regression testing to ensure that the fix hasn’t broken existing functionality.

Basically, ‘Regression Testing#regression #regressiontesting #testing #retest #Selenium #Winrunner #QTP #anarsolutions’, it is the process of re-testing already functional parts of a software project. Due to any changes, bug fixes or enhancements that are carried out, it is imperative to make sure that other fully working processes or modules in the software are left unharmed. It is a process that should be compulsory in any tester’s practice.

It is important to note that the same principle applies when a new feature or functionality is added to the existing application. In the case of new functionality being added, tests can verify that the new features work as per the requirement and design specifications while regression testing can show that the new code hasn’t broken any existing functionality.

When to perform Regression Testing?

Regression testing should be performed after any change is made to the code base. Additionally, regression tests should also be executed anytime a previously discovered issue has been marked as fixed and must be verified.

Your team will need to decide the regression testing schedule that best meets your needs, but most organizations find it useful to perform regression testing on a strict schedule. This may be at the end of every work day, weekly, bi-weekly, or even after every single repository commit is pushed. The more often your team can perform regression testing, the more issues can be discovered and fixed, which will lead to a more stable and functional piece of software at the end of development and leading into production.

Types of Regression Tests

As these are repetitive tests, test cases can be automated so that set of test cases alone can be easily executed on a new build. Regression test cases need to be selected very carefully so that maximum functionality is covered in a minimum set of test cases. These set of test cases need continuous improvements for newly added functionality. It becomes very difficult when the application scope is very huge and there are continuous increments or patches to the system. In such cases, selective tests need to be executed to save testing cost and time. These selective test cases are picked based on the enhancements done to the system and the parts where it can affect the most.

What are common Regression Testing Techniques?

• Unit Regression Testing – Immediately after coding changes are complete for a single unit, a tester – typically the developer responsible for the code – re-runs all previously passed unit tests.
• Smoke Testing – Smoke testing, also called Build Verification Testing, is a series of high-priority regression tests that are executed after code changes are merged, and before any other testing.
• Sanity Testing – Sanity testing is a subset of functional testing that examines only the changed modules. The goal of sanity testing is assurance that new features work as designed and that defects reported in prior testing have been resolved.
• Complete Regression – Also known as “retest all” technique, all regression test cases are executed in a complete regression. While a complete regression may be tempting for assurance that the application has been thoroughly tested, this is by definition costly and is not always practical, especially for minor releases. In general, a full regression test suite may be necessary for major releases with significant code changes, following major configuration changes such as a port to a new platform, or to assure compatibility with an updated operating system
• Partial Regression -As an alternative to a complete regression, a partial regression strategy selects only certain tests to be run. Tests may be selected based on the priority of the test case, or they may be chosen based on the particular module(s).

Regression Test of GUI Application:

It is difficult to perform GUI (Graphical User Interface) regression test when GUI structure is modified. The test cases written on old GUI either become obsolete or need to be modified. Re-using the regression testing test cases means GUI test cases are modified according to new GUI. But this task becomes a bulky one if you have a large set of GUI test cases.

Examples of Regression Testing tools are:

• Selenium
• Winrunner
• QTP
• AdventNet QEngine
• Regression Tester
• vTest
• Watir
• actiWate
• Rational Functional Tester
• SilkTest
• TimeShiftX

Most of these tools are both functional and regression test tools. Adding and updating regression test cases in an automation test suite is a cumbersome task. While selecting automation tool for regression tests, you should check if the tool allows you to add or update the test cases easily. In most cases, we need to update automated regression test cases frequently due to frequent changes in the system.

Best Practices in Regression Testing

• Maintain a schedule: Choose a schedule of testing you can maintain throughout the software development life cycle. This avoids cases where testing is placed on the back burner.
• Use a test management tool: Properly track all tests being performed on a regular basis, and have historical records of their performance over time. Do this using a simple test management tool of some kind. This can lead to more efficient decisions about what test cases must be executed. It can help pinpoint necessary improvements and changes in test cases. It can also drive clearer analysis of the regression testing outcomes.
• Evaluate test prioritization: Regression testing is more difficult when the application’s scope is large and there are continuous increments or patches to the system.

Thus, we can conclude that effective regression strategy, save organizations both time and money.

http://www.anarsolutions.com/regression-testing/utm-source=Blogger.com