In any software program, new releases or new versions are inevitable. Organization spend lots of money and resources to improvise the existing software. Continuous improvisation is necessary for any software product so that they can remain competitive in the market. On an average, every software is upgraded at least once in every year.

This arises the need of testing different aspect of software known as Backward and Upgrade testing. Considerable efforts are spent in making sure that software can be upgraded without affecting user in any adverse ways. With every new version of the product, one of the main criteria should be to make sure that whatever efforts user have spent on the older version, should not be wasted.

Though Backward and Upgrade testing are different, but both are very much similar as you will understand in the following section.

Backward Testing

Testing that ensures that new version of the product continues to work with the assets created from older product is known as Backward compatibility testing. For example, consider a simple case of Excel worksheet. Suppose you have created a very complex excel sheet to track your projects schedule, resources, expenses, future plans etc. Now if you upgrade from Excel 2000 to Excel 2003 and some of the functions stop working, you will not be delighted with this.

So crux of the Backward compatibility testing is to make sure that assets created using older version should continue to work.

In cases where it is not possible to use assets created by older versions due to any reason, then proper migration path should be given to the user so that they can migrate smoothly from old version to new version.

Upgrade Testing

Scope of upgrade testing becomes a bit broader than backward compatibility testing. In upgrade testing, apart from making sure that assets created with older versions can be used properly, we also make sure that user's learning is not challenged. We also make sure that upgrade process is simple and user do not have to invest lots of time and resources to upgrade the product. Following items can be included in upgrade testing, but not limited to

Upgraded product should continue to work with the same version of old component. For example, upgrade of your product should not force user to upgrade their database as well.

As far as possible, look and feel of the product should be changed incrementally so user feel comfortable with the upgraded product as well.

Same terminology should be used wherever possible.

Old functionality should remain intact, it should not be dropped until unless you have business reasons to drop it.