1.

Introduction
The Testing services department is involved in executing Testing Projects from various business entities across HSBC group. The customers are also involved in our testing projects, providing the clarifications on our queries, valuable suggestions and guidance to our testing team. In some cases they are also involved in reviewing our Test Cases. As a result of this we are writing our Test Cases in line with our customers existing projects and Templates. Due to this nature, it was observed that, Test cases are written in different style and different format in many of our projects. When new test executors are assigned to projects, they require sufficient time to go through the Test Cases and get familiar with them, apart from understanding the application and navigations. In order to avoid this we need to follow a consistent approach and format in writing Test Cases.

1.1.

Purpose

The purpose of this document is to provide some basic guidelines on how to write effective Test Cases for Functionality Test. All Test Analysts who are involved in writing Test Cases for System Test, System Integration Test and UAT should follow these guidelines.

The objective of this document is: To provide a document that can be used to illustrate the test Case preparation for all Test Analysts To provide an easy example of how to convert a business requirement into Test Case. To insist on consistent test case preparation approach in all testing projects

1.2.

Simplify Test Cases All Test Cases should be written in simple plain English. Test cases should contain series of test steps describing each action and navigation required to conduct the test if required. Test steps should always start from beginning of the application No project specific abbreviations used in Test Cases. In case they have to be used they should be clearly stated in the beginning. Each Test step should contain clear expected result without any assumptions. All input fields, mouse clicks and selects should be covered in the Test Steps if required. All prerequisites should be coved in the Test Steps No short cut navigations in Test Steps Include Input data in Test Step descriptions wherever possible .The test data sheet should be a part of the test case. The test data sheet should have references to the various test cases. There are no actions missing in Test Steps or no Test Steps missing. Use test case coverage checklist during review.

 Provide project details, author and complete all fields in Test Cases template. Mention date of creation, review and the version number. (The name of the test case document should be as specified in the SCM Plan and should clearly reflect the application, module and type of test (UT, ST, UAT).Keep the test case document under version control as specified in the Configuration plan.) Use test case review checklist during review.

2. Requirement to Test Cases

The following diagram explains how a business requirement is translated into Test Cases. The best approach is, every requirement should be split into its basic business functionalities. Again, each functionality should be split into its basic Test Scenarios, in order to simplify the process of Test Case creation. The Scenarios should include all positive and negative scenarios, which are close to real time business instances. These Test Scenarios and Functionalities are normally mentioned in Test Plan as Items to be tested and Items not to be tested. Each test Scenarios are further divided into Test Cases again including all positive and negative instances.

Requirements
Requirements

Functionalities
Functionalities

Test Scenarios
Scenarios

Test Cases
Test Cases

Test Steps
Test Steps Test Step-1

Requirement1

Function-1

Scenario-1

Test Case-1

Test Step-2

Test Step-3

Test Case-2

Test Step-1

Test Step-2

2.1.

Examples
The below mentioned example shows how a specific requirement is getting split into Functionalities and each functionalities then getting broken into Test Scenarios and each Test Scenario then broken into Test Cases and Test Steps.

Tes

Tes

2.1.1 Example-1
The subject is Withdrawal of cash Rs.13000 from ATM.. The expected result for the two test cases in this example is ATM should display message The Transaction Limit is Rs.12000 Requirements Cash withdrawal from ATM 1. Functionalities Withdrawal of standard Rs.1000 Withdrawal of standard Rs.2000 2. 3. Withdrawal of standard Rs.3000 Withdrawal of any other amount 3. 1. Test Scenarios Withdraw cash within allowed transaction limit Rs.12000 Withdraw cash grater than allowed Transaction Limit Rs.12000 Withdraw cash within allowed daily cash limit Rs.50000 1. Test Cases Withdraw cash Rs.13000 when account balance is Rs.60000 Withdraw cash Rs.13000 when account balance is Rs.5000 and no overdraw allowed 1. 2. 3. 4. Test Steps Check if ATM is active Insert ATM Card Type in PIN and Enter Select Cash withdrawal and Enter Select Any other amount option (Other than standard withdrawals Rs.1000, Rs.2000 and Rs.3000) On the Other Amount screen, enter amount to be withdrawn as 13000. Screen Error- The Transaction Limit is Rs.12000-Do you want to enter another amount? is displayed. Select No. Screen Do you want to do any other transaction? is

2.

2.

5.

4.

6.

7.

8.

displayed. Select No. Thanks screen is displayed. Collect ATM Card from ATM

2.1.2 Example-2 The subject is Transfer of funds between two accounts linked to the same card. .The expected result for the test case in this example is ATM should display the Transfer Confirmation Screen along with the new balances in the two accounts.
Requirements Internal Transfer application of ATM 1. Functionalities Transfer of funds between two accounts of the same currency. Transfer of funds between two accounts of different currencies. 1. Test Scenarios Transfer of funds when there are two accounts linked to the card. Transfer of funds when there are more than two accounts linked to the card. 1. Test Cases Transfer funds from Account-1 to Account-2. Transfer funds from Account-1 to Account-3. Transfer funds from Account-2 to Account-1. Transfer funds from Account-2 to Account-3. Transfer funds from Account-3 to Account-1. Transfer funds from Account-3 to Account-2. 1. Test Steps When the ATM is on the HelloWelcome Screen, insert the card and enter the PIN. The transaction menu is displayed. Select transfers followed by Internal Transfer. Account Selection Screen From Account is displayed. Select the account you want to transfer from i.e. Account 1. Account Selection Screen To Account is displayed. Select the account you want to transfer to i.e. Account 2. Amount Entry

2.

2.

2.

2.

3.

4.

3.

5.

6.

4.

5.

6.

7.

8.

Screen is displayed. Enter the amount you wish to transfer and press Enter Recap Screen displaying the From Account, To Account, and amount is displayed. Select Yes option. Transfer Confirmation screen is displayed. This displays the new balances in both the accounts. The application will ask the customer to select another application. Select No. Thanks screen is displayed. Collect the ATM record and card. Verify that the ATM record has the correct details.

2.1.3 Example-3
The subject is Addition of Payee based upon address details through net banking. The expected result for the test case is that the application should generate reference number and state that the payee addition process would be completed in 5 working days. Requirements Functionalities Test Scenarios Test Cases Test Steps

External Transfer/ Payment system in Netbanking

1. 2. 3.

Payee Maintenance Payment Maintenance Make immediate payment

1. 2. 3. 4.

Add Payee Modify Payee Delete Payee View Payee Details

1. 2.

3.

Add Payee Based on Address Add Payee based on Banking account number Add Payee based on International Banking account number.

1.

2.

3.

4.

5.

6.

Login to Net banking using customer ID/Password. Select the option Add Payee. The Add Payee screen is displayed. Select the option Based on Address details from the dropdown Payee Identification type. Screen asking for Payee details is displayed. Enter the Payee Name, Address, Pin, Phone Number and Fax Number. Press OK button. Confirmation screen showing the payee details entered. Press Confirm. Screen will displayed confirming receipt of payee details. It would give a reference number and state that payee addition process would be completed in 5 working days. Logout of net banking.

2.1.4 Example-4
The subject is Deposit application through ATM- Customer does not deposit envelope containing cheques when asked for. The expected result for the test case is that the ATM should display screen Did not receive the envelope. Requirements Deposit application in ATM 1. 2. Functionalities Deposit cash/cheques using ATM Envelope Payment using ATM 1. 2. 3. Test Scenarios Depositor down Deposit cash. Deposit cheques. 1. Test Cases Customer deposits envelope containing the cheques when asked for. Customer does not deposit envelope containing cheques when asked for. Depositor goes down when customer is doing the transaction. 1. Test Steps When the ATM is on the Hello/Welcome Screen, insert the card and enter the PIN. The transaction menu is displayed. Select deposit. Screen Cash or cheques is displayed. Select Cheques option. Account Selection Screen is displayed. Select the account you want to deposit into. Amount Entry screen is displayed. Enter the amount. Screen asking the customer to deposit the envelope containing the cheques is displayed. Do not deposit the envelope. The application will wait for 90 seconds and then display error screen Did not

2.

2.

3.

3.

4.

5.

6.

7.

8.

receive envelope. The application will ask the customer to select another application. Select No. Thanks screen is displayed. Collect the ATM card.

2.1.5 Example-5
The subject is Change/Defect tracking system-Recording of new defect. The expected result for the test case is that the new defect should be recorded and be present in the defect list. Requirements Change/Defect tracking system 1. 2. 3. 4. Functionalities Recording /Tracking of defects Tracking of change requests. Knowledge repository Test case tool 1. 2. 3. 4. Test Scenarios Recording of defect information Defect analysis Defect resolution Defect closure. 1. 2. 3. Test Cases Recording of defect. Changing defect related information Defect reports 1. Test Steps Login to the Defect tracking system with privileges of Tester. Select option STR (Software Trouble report or defect). Select Add STR. Fill in the required details like Date reported, Reported by, Module Name, Severity, Priority, Status, Defect Summary, Defect detail, Reproducibility. The status should be set to Open (Evaluation).

2.

3.

4.

5.

6.

7.

Select ADD. The STR will be created. Note down the STR number. Select STR Summary and verify that the STR is added correctly. Logoff and Login to the Defect tracking system with privileges of Developer. We should be able to view the STR details but not modify them. However we can work on the Analysis section. Logoff from the Defect tracking system.

2.1.6 Example-6
The subject is Railway Reservation SystemBooking HistoryCancelled Tickets History. The expected result for the test case is that the user should be able to view the Cancelled Tickets History. Requirements Railway Reservation System 1. 2. 3. Functionalities Book/Cancel a Ticket Booking History User Profile maintenance 1. 2. 3. Test Scenarios Booked History Cancelled Tickets History Failed Payments History 1. Test Cases Track using PNR (Passenger Name Record) Number Track using transaction ID Track using From Station To 1. Test Steps Logon to the railway reservation system using the appropriate user id and password. Select Booking HistoryCancelled

2. 3.

2.

Station.

3.

4.

5. 6.

Tickets History. The user is asked to reenter the password. The user is presented the options of tracking using PNR Number, Transaction ID or From Station/To Station. Enter the PNR Number and press Search. The cancelled ticket details are presented. Select on the record to view the details. Logoff from the Railway reservation system.

2.2.

Consistent Test Case writing Write Test Cases using QC template only Create a Scope for Test Cases as Requirements, Associated Functionalities, associated Scenarios for each functionality Write Test cases for all Business Requirements without missing any. Use requirement traceability matrix. Write Test cases for all Functionalities under each Business Requirement without missing any functionality Write Test Cases for all negative and positive scenarios of all functionalities Write Requirement reference numbers and functional reference numbers in each Test Case. The documents being referred to should be clearly mentioned. This includes the version number and date of the document. Write unique Test Name and Test Case id for each Test case. The test name should relate to the application and module being tested. Write a meaningful Subject in Subject field for each Test Case Write a clear test case description in plain English without any abbreviations.

 Any abbreviations or terminology used in the test cases should be clearly mentioned in the beginning. Write a unique Test Step Name Write a clear Test Step description in plain English for each action to be carried out