Test CaseWriting

August, 2011

2

From Requirements to Test Case Workflow

3

Definition – Test Case

What is a Test Case?

Definition 1A set of test steps, execution conditions and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.

Definition 2Test cases are specific inputs and procedures that you will follow when you test software.

AnalogyA Test Case is like a recipe. You follow the steps to produce an end result.

4

Basic Parts of a Test Case

A Test Case is multiple Steps which are comprised of these 4 basics parts:

1. Description of the Test CaseVerify that the text is blue.

2. Description of each StepLocate text in first paragraph

3. Expected result each StepThe text should be blue

4. Actual result each StepThe text is blue

5

Test Step

A Test Step is the smallest portion of a Test Case. It typically describes a single action in a chain of actions which go on to comprise a Test Case:

1. Usually start with a verb such as:Verify, Validate, Navigate

2. Usually are doing something very discrete.Validate color, Verify SSN, Navigate to account

Examples:Step 1. Navigate to SSN field. Step 2. Enter a valid ID.Step 3. Validate that the SSN field will only accept a 9 digit number

6

Test Cases Structure Example

Test Cases:

Open a new consumer customer checking account

• Step 1 Description • Expected Result• Actual Result

• Step 2 Description• Expected Result• Actual Result

• Step 3 Description• Expected Result• Actual Result

Open a new consumer customer savings account

• Step 1 Description • Expected Result• Actual Result

• Step 2 Description• Expected Result• Actual Result

• Step 3 Description• Expected Result• Actual Result

7

Things to Consider

Points to keep in mind when writing Test Cases:

1. Test Data needs2. Environment needs3. “Log on” (user ID) needs4. Hardware needs5. Batch requirements6. Interfacing applications (up and down stream)7. Positive and negative scenarios* 8. Boundary Test (how big/small can I go and what

happens if I do)**

* Written Test Cases should focus should be Positive scenarios, in addition to “worst-case” scenarios; however, Negative testing may be done Ad Hoc during the test execution phase.** Boundary testing should have been covered during Product Test.

8

Best Practices

When writing:

1. Avoid lingo (words, abbreviations, acronyms and phrases used in your department or field)

The customer will be using ABF financing.The customer will be using Asset Based Financing.

2. Write the case as if you are not going to be executing it.

Report should look like Bettys report.Output should be TPS 123 report.

3. Write Test Cases so they Test a limited set of functionality.

Verify that all Deposits work in Alnova.Execute a deposit in Alnova.

9

Example Test Case with Steps

For existing consumer and commercial accounts, add an alternative contact address for a statement address using this mailing address: 123 Maple Street, Birmingham, AL

Test Case: Open an existing consumer account: Test Step 1. In business object, enter

last name of customerTest Step 2. Choose Add an Address Test Step 3. Enter 123 Maple StreetTest Step 4. Etc….

10

Additional Example - Scenario

SCENARIO

Example Re-written IssueModify Consumer Credit overdraft protection. Consumer Customer modifies their

Courtesy Overdraft Protection selection made to an existing activated checking account in a Migrated/Converted Branch.

Not enough detail was provided so that the individual writing the Test Cases could understand specifically what the Scenario writer intended to be tested.

11

Additional Example – Test Case

TEST CASE

Example Re-written Issue1. Log into RM2. Modify an existing users overdraft protection

1. Log into RM2. Enter Consumer Customer who has an existing activated checking account at a converted branch3. Modify Overdraft Protection4. Validate that change is noted in Alnova

Not enough detail was provided in the first example to execute the case correctly.

12

UAT Scenario Naming Convention

Department_Type_ Test Scenario Number_Description• Department = See Department Abbreviation 06-28-2011.xls

for a list of the Department abbreviations.• Type = Use an abbreviation of the type of transaction that

allows you to best identify the Test Scenario• Test Scenario Number – Incremental Number• Description – Brief description of the event that you are

testing ExampleRET_CONSREG_001_Register a Customer This means Retail Department – Registering a Consumer – Incremental number - Scenario Description

* 001 is the scenario number and is the number used in the Test Case naming convention

13

UAT Test Case Naming Convention

Department_Type_ Test Scenario Number_Test Case Number _Description• Department = See Department Abbreviation 06-28-2011.xls

for a list of the Department abbreviations.• Type = Use an abbreviation of the type of transaction that

allows you to best identify the Test Scenario• Test Scenario Number – Incremental Number• Test Case Number – Incremental Number (May have multiple

Test Cases per Test Scenario)• Description – Brief description of the event that you are

testing

ExampleCM_NCONMAINT_001_002_Register a Customer This means Commercial Department – Non-Consumer Maintenance – Test Scenario number– Test Case Number – Test Case Description

14

Scenario Applied to Test Cases

How Scenarios Can be Used for Your Test Cases

15

Test Case Template

Test Case Template

16

Test Case Template Column Definitions

Test Case Template

COLUMN Subject Test Name Description Pre-Requisites Test Data Test Priority Type Test Attributes Requirement ID Step Name Description (Design Steps)

Expected (Design Steps)

DESCRIPTION This field pertains to the path where the test case will be stored in ALM. If you are unsure what to put in this field then leave it blank.

This is the name by which all test Steps are grouped and will be what is displayed within the tool. Each row that pertains to a specific test case should all have the same name. Avoid using special characters like %$<> etc in the name.

This field should be used to describe at a high level what you are trying to accomplish with your Test Case.

This field should be used to describe anything that needs to occur as a precursor to executing the Test Case.

This field is used to describe any data needs required to execute the Test Case.

Used to establish a priority for the Test Case should a risk based testing approach be required. For our purposes all tests should be marked as an "A".

Type should primarily be set to Manual and is only necessary to fill in on the first line of each  Test Case.

Test Attributes should contain the type of Test Case it is such as Integration Test, System Test, Product Test, etc and should only be filled in on the first line of the Test Case.

This filed should reference the specific requirement or group of requirements which a specific Test Case is covering. It should only appear on the first line of the Test case.

This field needs to be populated with the discrete "Step" name in the format Step #... When using a single tab for multiple Test Cases each discrete Test Case should begin with Step 1.

This field should include the details for executing the Step. It should be written in such a way that a user with limited experience can execute it.

This field should describe what the person executing the Step would see upon completing the instructions described in "Description (Design Step)."

EXAMPLE FunctionalityAlnovacards

CIF_1_00_01 Validate that a users alternate contact info can be stored.

Need credentials for RM

Need account numbers where users have alternate contact info.

A Manual Integration Test 1.1.1 Step 1 Log into Alnova User is able to log into Alnova

These are the definitions for each column:These are the definitions for each column:

17

UAT Test Case Template Required Fields

• The first row of every test case must have some value in every cell except A

• Subject (cell A) - can be left blank• Test Name - can not exceed 40 characters• Test Name - can not have any unique characters such as , : ; ‘ < () /\ ^

" *• Test Name - can have an underscore or a period (_ . ) along with

numbers and letters• Description, *Pre-Requisites, or *Test Data – if these fields on the first

row of a test case are blank, enter TBD or N/A in the field/s• Test Attributes - for UAT test cases must say “User Acceptance Test”• Test priority - must be either A (high), B (medium) or C (low)• Requirement ID - should only list the most applicable requirements• Type - Manual• All following cells (in the rows below the first line) must be blank

except the design steps (Step Name, Description – Design Steps, Expected– Design Steps)

• Remove Blank rows between tests (they will not be accepted by ALM)

*Pre-Requisites = items (non-data) required to perform the test such as hardware, environment needs, batches (example: ATM cards)*Test Data = data required to perform the test (example: valid account information)

18

UAT Test Case Template Requirements

• The first row of every test case must have some value in every cell - Manually add if missing

• Subject on the first row of every test case must have the path to the upload destination. For example: UAT/Rel 1.0/RET for Retail

• Test Name - can not exceed 40 characters - Manually correct• Description - can not have any unique characters such as , : ; ‘ < () /\

^ " * Manually remove any unique characters before uploading

• Description - can have an underscore or a period (_ . ) along with numbers and letters

• Description, Pre-Requisites, or Test Data – if these fields on the first row of a test case are blank, enter TBD in the field/s – Add these if possible or TBD

• Test Attributes - for UAT test cases must say “User Acceptance Test”• Test priority - must be either A (high), B (medium) or C (low)• Requirement ID – only one ID is accepted, remove all others• Type – Manual• All following cells (in the rows below the first line) must be blank

except the design steps (Step Name, Description – Design Steps, Expected)

• Remove Blank rows between tests (they will not be accepted by ALM) Manually add/remove any blank rows

• If first row has any blank cells, add TBD or N/A

19

Test Cases in ALM

20

Example of Test Case and Test Steps

21

Sharepoint Link to UAT Naming Conventions

http://projectdocuments.compassbnk.com/platformupgrade/Core/Forms/AllItems.aspx?RootFolder=%2fplatformupgrade%2fCore%2fTest%20Coordination%2fR1%2fUAT%2fUAT%20%2d%20R1%20%2d%20UAT%20Tester%27s%20Area&View=%7b047D9B21%2dA186%2d40D5%2dB21F%2d406DD2C061CA%7d