This article describes what ported applications are and how to effectively test them.
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
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