Test cases for the migration project: importance and sample format

What are test cases and why are they important?

Test cases are formal examinations designed to validate certain functionality from the legacy system that should be preserved in the migrated application, that is, when the project goal was functional equivalence. In other words, they are sets of conditions or variables used to verify that the generated application is working as expected. These cases are documented in a test plan to act as a checklist for the quality assurance (QA) phase.

It is important that all the test cases used to assess the migrated application be fully detailed in its process and expected results. From the perspective of the QA team, test cases are used to:

• Understand the application to be migrated, from a functional standpoint.

• Ensure that the resulting application has the same behavior as the original one.

• Find any defects that may have been caused by the migration process.

Because of this, test cases become a source of knowledge that can be accessed at any moment and by several testers at the same time. This is quite useful when new QA resources join the team. The absence of this meticulous documentation can be mitigated by a knowledge transfer, but a knowledge base of the application’s functionality must be available. In ArtinSoft’s experience, this has been alleviated sometimes by the customer recording a series of specifications in video. Some other clients have provided one QA resource at certain points of the Testing phase, to work as an advisor for the ArtinSoft team, along with some knowledge base around the application.

Test cases also work as the Acceptance Criteria for the project; if they are not well defined, it becomes difficult to determine the assignment’s end point. At the same time, test cases provide a way to measure the progress of the testing and stabilization activities of the project.

The role of test cases in an ArtinSoft migration project

In general terms, test cases perform the following functions in a migration project handled by ArtinSoft:

• Help the ArtinSoft Consulting and QA teams to understand the application being migrated. During the last 2 years, ArtinSoft migration projects have also included a phase early in the cycle in which the test cases provided by the client are validated against the original application, to verify that they are self-explanatory and provide the expected results. This also helps ArtinSoft’s teams to review and understand the functionality of the application. The Development team uses the Test Cases as well, to direct a Developer Testing activity that takes place before the migrated application is submitted to ArtinSoft’s QA staff.

• Provide a way to corroborate that the migrated application is functionally equivalent.

• Understand which areas of the application are critical from the customer’s standpoint.

• Provide a way to track the progress of the stabilization and testing activities. The number of passing vs. failing test cases, as well as the number of active vs. closed bugs, are metrics that are constantly shared with the different stakeholders from ArtinSoft and the client, to provide information on the project’s advance.

• Provide a way for the client to have a higher involvement in the migration project.

• Provide a clear and well-defined Acceptance Criteria for the project.

Is it possible to use automated testing strategies and tools?

Automatic test cases can be used to test the application once it has been migrated, since they need the user interface to be stable: as most automatic testing engines rely on this, frequent changes to the user interface may render the automatic test cases invalid. This makes it unpractical to use this type of test cases during a migration. Automatic Test Cases developed for the VB6 application would not work on the migrated version.

In spite of this, automatic Test Cases have been used on the following scenarios:

• Applications with a web interface that is not expected to change in any way during the migration process.

• Business logic components with unit test cases developed for .NET only.

There are many automatic testing and bug tracking tools in the market. It is recommendable that each customer evaluates available options according to his requirements before making a decision, but in several recent projects we have seen that many of our clients use Quality Center.

Sample format

The following is an example of a test case:

[Test case title]

Project Name: [Specify project name here]

Test Case Objective: [for example, “To calculate charges for a monthly bill”]

Test Case ID: [type here]		Author: [author name]		Testing Phase: [Supplier Testing, User Acceptance Testing, etc]
Functional Area [Type here the functional area and a description of the functionality that will be tested. Example below:] 5.6.48 Product Pricing **Note** The term “designated action button” listed in the Expected Results (where applicable) is visible in the associated screen shots as the button that has a dotted-line which forms a rectangle around the name on the button, but this dotted-line rectangle is located just inside the edges of the button itself**				List any test cases that should be run prior to this test case

Input Specifications		[Specify detailed input specifications for this test case]
Output Specifications		[Specify detailed output specifications for this test case]
Environmental Needs		[Specify here any environmental pre-requisite to successfully execute this test case]
Special Requirements		[Specify here any special pre-requisite to successfully execute this test case]
Tester Name:		Test Date:
Tester Signature:		Pass/Fail

Test case steps

[Type here the detailed steps of the test case using the following table]

Step No.	Procedure/Description		Expected Results		Pass Fail	Comments
[ID]	[Procedure or description]		[Specify a detailed description of the expected results after executing this step]		[Yes/No]	[Specify here any additional information for this step]

The following are some examples of how steps should be specified in this section:

Step No.	Procedure/Description		Expected Results		Pass Fail	Comments
1	Log on to the application		The application screen appears with all buttons & vertical scroll bar (on right side of screen) enabled. “START” button is the designated action button. Message at top of screen: “Select the application you want to run, and click the ’start’ button (or you can double click the icon)”

Step No.	Procedure/Description		Expected Results		Pass Fail	Comments
2	The application screen appears with all buttons & vertical scroll bar (on right side of screen) enabled. “START” button is the designated action button. Message at top of screen: “Select the application you want to run, and click the “start” button (or you can double click the icon)” Highlight the “Product Pricing” icon by clicking on the icon once		The application screen now appears with the previously selected icon (Product Pricing) highlighted & the “START” button has changed to “START PRODUCT PRICING” & is no longer the designated action button

Step No.	Procedure/Description		Expected Results		Pass Fail	Comments
3	The product screen now appears with the previously selected icon (Product Pricing) highlighted & the “START” button has changed to “START PRODUCT PRICING” & is no longer the designated action button Click “START PRODUCT PRICING” button		Logon screen appears with Logon ID field seeded with performer’s ID & Password field blank. The cursor is automatically seeded in the Password field. Continue & Cancel buttons enabled. Message in blue: “Enter your Logon ID and Password”

Step No.	Procedure/Description		Expected Results		Pass Fail	Comments
4	Logon screen appears with Logon ID field seeded with performer’s ID & Password field blank. The cursor is automatically seeded in the Password field. Continue & Cancel buttons enabled. Message in blue: “Enter your Logon ID and Password” Enter Password

Step No.	Procedure/Description		Expected Results		Pass Fail	Comments
5	Click the Continue button		Calculate Utility Price screen appears with all radio buttons, drop down arrows, & buttons enabled except the “maximize” caption button. The Base Determinants area displays the following enabled fields: “Service Begin Date:”, “Service End Date:”, “Bill Date;”, “Bill Month:”, “City, State:”, & “County:”. All fields are blank. The blank “Service Begin Date:” field is highlighted. The “Price Profile:” & “Tax Profile:” fields are also blank but disabled. The Profile Specific Determinants area displays a table with the Description, Value, & Type columns blank & disabled.

Step No.	Procedure/Description		Expected Results		Pass Fail	Comments
6	Calculate Utility Price screen appears with all radio buttons, drop down arrows, & buttons enabled except the “maximize” caption button. The Base Determinants area displays the following enabled fields: “Service Begin Date:”, “Service End Date:”, “Bill Date;”, “Bill Month:”, “City, State:”, & “County:”. All fields are blank. The blank “Service Begin Date:” field is highlighted. The “Price Profile:” & “Tax Profile:” fields are also blank but disabled. The Profile Specific Determinants area displays a table with the Description, Value, & Type columns blank & disabled. Click the drop down arrow beneath the highlighted “Service Begin Date:” field		A Calendar screen appears & becomes the enabled screen on top of the Calculate Utility Price screen. The enabled Calendar screen displays the current month & year (i.e. May 2009) with the </> (forward & backward) arrows & today’s date circled in red.

Step No.	Procedure/Description		Expected Results		Pass Fail	Comments
7	A Calendar screen appears & becomes the enabled screen on top of the Calculate Utility Price screen. The enabled Calendar screen displays the current month & year (i.e. May 2009) with the (forward & backward) arrows & today’s date circled in red. Use the arrows scroll to back or forward to select applicable Month & Year (i.e. July 2008)		The Calendar screen remains the enabled screen (still visible on top of the disabled Calculate Utility Price screen) now with the applicable Month & Year displayed (i.e. 07/2008). This enabled Calendar screen still displays today’s date highlighted in gray (even though this is for the month of July 2008).

Step No.	Procedure/Description		Expected Results		Pass Fail	Comments
8	The Calendar screen remains the enabled screen (still visible on top of the disabled Calculate Utility Price screen) now with the applicable Month & Year displayed (i.e. 07/2008). This enabled Calendar screen still displays today’s date highlighted in gray (even though this is for the month of July 2008). Click on the date wanted (i.e. 28)		Calculate Utility Price screen with the “Service Begin Date:” field highlighted & seeded with the date & month selected in the previously enabled Calendar screen (appears as 07/28/2008)