Testing Ported Applications

Porting as the name suggest, Porting is the process of adapting software so that an executable program can be created for a computing environment that is different from the one for which it was originally designed (e.g. different CPU, operating system, or third party library). The term is also used in a general way to refer to the changing of software/hardware to make them usable in different environments. The term is not generally applied to the process of adapting software to run with less memory on the same CPU and operating system, nor is it applied to the rewriting of source code in a different language (i.e. language conversion or translation).

Most of the time software developers claim that the software they write is portable, meaning that it will require little or no effort to adapt it to a new environment. All the time the amount of effort needed depends on several factors, including the extent to which the original environment (the source platform) differs from the new environment (the target platform), the experience of the original authors in knowing which programming language constructs and third party library calls are unlikely to be portable, and the amount of effort invested by the original authors in only using portable constructs (platform specific constructs often provide a cheaper solution).

Sometime people get confused between Migration and Porting, Migration is a type of Porting but within the same system software i.e. says we are working on Application X.X and there is a new version available in market Application Y.Y of the same software then we are doing a migration and not porting.

Let us see how Porting activities can be done.

Porting Concept and how it work
Porting team should be considered as a stand alone team with. Usually a Water fall model will be the best suit for the Porting because the porting is done for the application which is already built by a company. Hence no requirement changes no Project Change request strikes the porting work.

Porting usually happens in the three steps mentions below.

First Step: This involves creating config specs and streamlining the database. Most of the time porting is done with different database say SUN-WLS-ORL, AIX-WAS-DB2 and W2K-WLS-SQL. Each environment is considered to be a component here. Development team get involves in creating the build with latest config specs and Database team involves themselves in creating appropriate database scripts.

Second Step: : This stage involves SCM i.e. Software Configuration Management team to write scripts which can deploy the application on different platform an installer is created. Test team get gets all the information from the Reference Team (This is the group who is responsible for testing the application in-house on), an application handover is done; which also includes the defects summary sheet, test cases status and setup requirements if any.

Third Step: This stage is purely testing, Porting testing is done as System testing. All the tests which are supposed to be working fine on a Reference Platform should be working fine on ported platform. Usually a re-test is carried out on ported environment. Defects are again tested on the reference environment to re-check and confirming that the defects are either Porting or Core defects.

Testing a Ported application (Testing a Web Based –Three-tier Banking Application)
Reference Environment: W2K-WLS-DB2.
Porting Environment: SUN-WLS-ORL
                                       AIX-WAS-DB2

Reference team had created total 1000 test cases which are in there test suit. Out of this according to there status report 934 test cases are passed and rests of the test cases are either Failed or Blocked. Porting Scope now is reduced to test these 934 test cases as the test cases which are failing on reference environment will fail on ported environment.

All the test cases will be copied to the Porting Test suits/domain either using Test Management Tool. Handover document will be prepared by the reference team which will include all the information including the Defect Summary, Workarounds, Known defects and the most important reference environment details with Test Support System and Release coordinators details.

Porting Testing will start with the Smoke Testing, where the AUT will be functionally tested if it contains any issues. Followed by a regression test set is executed (which consists of the 934 test cases). Now if Tester finds any defect, he executes the same test case on reference environment and validate if it is a reference defect, if the defect founds to be a reference defect and is a kind of show-stopper defect then it Development manager is called upon and estimation time to fix the defect is taken. The Defect logged here is raised against Reference Environment and is considered as a Defect Leakage. Other wise the defect is fixed at by the Porting development team and re-tested before handing over the application to Client. All the defects which are raised against porting environment are converted as Test Case and the same are executed at the time of delivering the product to customer.

Summary
Porting is most versatile activity, most of the customer has there own likes and dislikes about different OS/application server and Database servers. Porting gives a view to test this kind of application. Porting testing can be considered to be the last quality gate before delivery. Most important for Porting Testing is, both the teams Reference and Porting should be two different team managed by different Business Units. Communication and Test System Support is really important for Porting activity.