Testing of Ported Software

When porting, our QA team is engaged on the earliest steps.

At first, at QArea we need to make sure that the software to be ported has no bugs, or these bugs are documented in full (no bug has been overlooked). For this purpose the QA team creates test cases. Then, the test cases are run with the original application on the source platform. These test cases are then used to test the ported application (they can be used either in full, or partially, or as a basis for the new test cases to be written - dependent on platforms diversity). After the test cases are done, the application's bottlenecks are defined and the testing plan is drafted, than the Test Plan is generated.

It is now QArea can outline the following steps:

  1. Comparing Applications
    During this step the two applications, the source one and the target one, are compared in order to make sure the functionality has not been lost. Generally, a features list is generated where data is recorded whether a feature is implemented or not. This list helps us to ensure the complete range of application features has been ported.
  2. Testing Differences
    During this step all the differences in the source application and the ported application are tested and documented. Particular attention is paid to modifications that have been introduced to application GUI and design. These modifications are often when porting software to a platform which is significantly different from the source one, as well as during software localization. It is on this step that it is critically important to check for all the resources in the target application, as well as their distribution (so that to avoid the situations when half of the resources is in one language and the other is in another language. These bugs are very often when software localization).

    In case of application porting to another platform, GUI testing may consume quite a time. During this step it is extremely important to make sure changes to the application user interface and design do not affect the functionality (all the targeted functionality has been achieved).

    During this step we also focus on modifications to functionality testing. In some ported applications functionality undergoes certain changes. In such cases we track for the reasons of such variance in functionality, as well as whether they are justified or not.

  3. Checking for Bug Fixing
    During this step QArea's quality assurance team performs initial testing of all bugs that were detected in the source application to make sure they do not exist in the ported application.
  4. Complete Testing
    This is the completing step.
    During this, the ported software is exposed to all tests that were developed and described in Test Plan. In fact, during this step the software functionality is tested regardless of whether it was subject to modifications or not during porting.
    At the end of this step a conclusion is made whether the product is ready for submission. In case it is not, the product is sent to further analysis and developing, and next it is tested again.

Finally, a document is developed containing the description of the ported software along with the listing of its deviation from the original application, as well as conclusions as to porting success.

These conclusions are based on:

  • functionality completion (all the required features have been ported)
  • absence of bugs (both those old ones deriving from the original application and those new ones in the target application)
  • modifications to functionality and GUI, and their affect on porting success (their affecting the final product)
Request a Quote

* Please fill in fields with asterisk.

Request a Call

* Fields with asterisk are mandatory for filling.