Software QA FYI - SQAFYI

Upgrade Path Testing

By: Dhiraj Lokhande

Upgrade Path Testing

Upgrade path testing, also called up-gradation testing, sounds a bit unusual. But testing upgrades is an important part of the software life cycle. What exactly does upgrade path mean to software? Suppose your company developed a product which was rolled out into the market with version 1.0. Due to few showstopper defects, your company needs to deliver version 1.1 which could be a Patch or a Hot Fix. What are the different things which should be evaluated and tested so that we can say the up-gradation is working correctly? How do we test an upgrade? On a high level, we test an upgrade path using the following techniques: » Installation Testing » Database Testing » Application Testing » Documentation Testing

Installation Testing

Why is this type of testing required?
When you are delivering a new version with bug fixes there is a high possibility that the code is changed or modified. Installation testing helps confirm that the right changes are going into the correct folders. For example, suppose there is a folder which contains all the HTML files which have updated. Does the CSS folder also need to be updated? If we update the HTML files without updating related CSS files, the color/fonts and other attributes will not be reflected correctly.

How do we test?
Most of the time, installation testing is done with the help of the Software Configuration Management (SCM) team as we have to evaluate both the old system and the upgraded path.

The first testing is folder level validation. All folders with the timestamps are checked so we can revisit which are the folders that are copied to the system by this installation procedure.

Second the size of the files which are modified are tested and compared with the earlier version. This could be white or black box testing. In white box testing, the tester must open the file and check if the code actually exists or not. In black box testing the tester must check the file size since it should definitely differ from the old file size. If the tester finds any discrepancies he or she can open a defect with HIGH severity and HIGH priority.

Some companies perform installation testing for the complete application. For example, suppose a new company would like to buy version 1.1 directly and is not concerned about the issues or settings for V1.0. Installation testing must be performed for this scenario in a similar manner.

The diagram below shows the verification of the installation testing process. New code is copied into a folder “patch” and the tester views the change in the timestamp of the folder.

Database Testing

Why is this type of testing required?
Database testing will play a significant role since it will start with the upgrade script. This testing will be done with the Database Administrative team (DBA).

How do we test?
The database instance needs to be stopped or brought down and a backup of the database will be taken and stored. An Upgrade Script will be executed and a new database will be delivered. The tester must open the database log file and check if all the records are inserted or applied correctly. Any database error is reported as a defect.

Most often either a new table or a relation is added to the database; hence the strategy for database testing lies in testing the BLANK database, i.e. the first install the Default Database V1.0. This database will have only the tables and relation and not the “DATA” as such.

Then the tester must apply the alter scripts (Upgrade Script) and check if there are any errors in the log file. If there are no errors, connect the Database with the application and try to execute few test scenarios which have the basic flow of the application. This is done to make sure that the data is correctly being entered into the application and to verify there is no error for inserting or updating any database record.

Full article...

Other Resource

... to read more articles, visit

Upgrade Path Testing