Writing Test Cases 20110808
- 2. From Requirements to Test Case Workflow
- 3. Definition – Test CaseWhat 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 CaseA Test Case is multiple Steps which are comprised of these 4 basics parts:Description of the Test CaseVerify that the text is blue.Description of each StepLocate text in first paragraphExpected result each StepThe text should be blueActual result each StepThe text is blue
- 5. Test StepA 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:Usually start with a verb such as:Verify, Validate, NavigateUsually are doing something very discrete.Validate color, Verify SSN, Navigate to accountExamples: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 ExampleTest Cases: Open a new consumer customer checking accountStep 1 Description
- 10. Expected Result
- 11. Actual Result
- 13. Expected Result
- 14. Actual ResultOpen a new consumer customer savings accountStep 1 Description
- 15. Expected Result
- 16. Actual Result
- 18. Expected Result
- 19. Actual Result
- 21. Expected Result
- 22. Actual ResultThings to ConsiderPoints to keep in mind when writing Test Cases:Test Data needsEnvironment needs“Log on” (user ID) needsHardware needsBatch requirementsInterfacing applications (up and down stream)Positive and negative scenarios* 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.
- 23. Best Practices When writing: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.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.Write Test Cases so they Test a limited set of functionality.Verify that all Deposits work in Alnova.Execute a deposit in Alnova.
- 24. Example Test Case with StepsFor 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….
- 25. Additional Example - Scenario
- 26. Additional Example – Test Case
- 27. UAT Scenario Naming Convention Department_Type_ Test Scenario Number_DescriptionDepartment = See Department Abbreviation 06-28-2011.xls for a list of the Department abbreviations.
- 28. Type = Use an abbreviation of the type of transaction that allows you to best identify the Test Scenario
- 29. Test Scenario Number – Incremental Number
- 30. 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
- 31. UAT Test Case Naming ConventionDepartment_Type_ Test Scenario Number_Test Case Number _DescriptionDepartment = See Department Abbreviation 06-28-2011.xls for a list of the Department abbreviations.
- 32. Type = Use an abbreviation of the type of transaction that allows you to best identify the Test Scenario
- 33. Test Scenario Number – Incremental Number
- 34. Test Case Number – Incremental Number (May have multiple Test Cases per Test Scenario)
- 35. Description – Brief description of the event that you are testingExampleCM_NCONMAINT_001_002_Register a Customer This means Commercial Department – Non-Consumer Maintenance – Test Scenario number– Test Case Number – Test Case Description
- 36. Scenario Applied to Test CasesHow Scenarios Can be Used for Your Test Cases
- 37. Test Case TemplateTest Case Template
- 38. Test Case Template Column Definitions These are the definitions for each column:Test Case Template
- 39. UAT Test Case Template Required FieldsThe first row of every test case must have some value in every cell except A
- 40. Subject (cell A) - can be left blank
- 41. Test Name - can not exceed 40 characters
- 42. Test Name - can not have any unique characters such as , : ; ‘ < () /\ ^ " *
- 43. Test Name - can have an underscore or a period (_ . ) along with numbers and letters
- 44. 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
- 45. Test Attributes - for UAT test cases must say “User Acceptance Test”
- 46. Test priority - must be either A (high), B (medium) or C (low)
- 47. Requirement ID - should only list the most applicable requirements
- 48. Type - Manual
- 49. 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)
- 50. 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)
- 51. UAT Test Case Template Requirements The first row of every test case must have some value in every cell - Manually add if missing
- 52. 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
- 53. Test Name - can not exceed 40 characters - Manually correct
- 54. Description - can not have any unique characters such as , : ; ‘ < () /\ ^ " * Manually remove any unique characters before uploading
- 55. Description - can have an underscore or a period (_ . ) along with numbers and letters
- 56. 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
- 57. Test Attributes - for UAT test cases must say “User Acceptance Test”
- 58. Test priority - must be either A (high), B (medium) or C (low)
- 59. Requirement ID – only one ID is accepted, remove all others
- 60. Type – Manual
- 61. All following cells (in the rows below the first line) must be blank except the design steps (Step Name, Description – Design Steps, Expected)
- 62. Remove Blank rows between tests (they will not be accepted by ALM) Manually add/remove any blank rows
- 63. If first row has any blank cells, add TBD or N/ATest Cases in ALM
- 64. Example of Test Case and Test Steps
- 65. Sharepoint Link to UAT Naming Conventionshttp://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