Backword Testing

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.
Recent Updates
Guerrilla Testing Tips
One CPU better than two
TG Tips For Automation?
Is It Really Done?
Exploratory Testing
Automated Testing
Model Based Testing
Live News
 
Read More
Accessibility API Testing Article Backword BigBang Blackbox Blog Bottomup Boundary CaseStudies Certification DefectReport DistanceTest Equivalence FitNesse Geeks Graybox Guerrilla Testing Tips GUI HTA Humor Hybrid Internationalization Installation Integration Is it done? JUnit Measurement Mercury Quality Centre News One CPU better than two Patent Performace Checklist Rational Test Suite Regression Requirement Verification Research Rational Functional Tester Security Selenium SilkTest System Testing Templates TestComplete Tools Testing Types Testing Tools In News Testing Terms In News Testometer Test Plan TG Tips For Automation Top Down Integration Trait UAT UI Testing CheckList Unit Testing Usability VMWare Web Application Security Web Application Testing Checklist Whitebox Testing
Disclaimer  |  Privacy Policy  |  g e e k AT T e s t i n g G e e k DOT c o m
© Copyright 2008, www.TestingGeek.com