Test Case Planning

Test Case Planning Form Components • Analyst Name: • Product Name/Release: • Requirements/Descriptions: • Defects/Descriptions: • Use Cases: • Testing Strategy for Requirements/Defects: • Test Case Listing for Requirements/Defects/Use Cases: • Assumptions {mosgoogle} Test Case Planning Form Components • Analyst Name: • Product Name/Release: • Requirements/Descriptions: • Defects/Descriptions: • Use Cases: • Testing Strategy for Requirements/Defects: • Test Case Listing for Requirements/Defects/Use Cases: • Assumptions Test Case Components • Test Case Statistics • Summary of Changes • Objective • Associated Test Specifications: • Objective Details • Review Checklist Information • Test Configuration • Detailed Test Script Why is Test Case Quality So Important? • High Risk • Unclear Steps & Results • Better Tests – More Reliable Results – Lower Costs in 3 Categories: • 1. Productivity - less time to write and maintain cases • 2. Testability - less time to execute • 3. Scheduling reliability- better reliability in estimates {mosgoogle} Best Practices • Accurate • Economical • Repeatable; Self-Standing • Appropriate • Traceable • Self-Cleaning 7 Most Common Mistakes Test Cases too Long Incomplete, Incorrect, or Incoherent Setup Leaving out a step Naming Fields that Change or No Longer Exist Unclear if Tester or System does Action Unclear What is a Pass or Fail Result Failure to Clean Up{mosgoogle} Common Pitfalls – Input from TIM Test Leads • Ensure There is No Danger of Database Damage or Data Corruption • Consider the Big Picture of the Actions Taken in any Test Case. • Before Making ANY changes to a Database – Verify This Action with a Test Architect for the Application More Common Pitfalls • Test Approaches • Test Cases • Types of Test Cases • Number of Requirements per Test Case - KISS • Test Case Naming Conventions • Properties - Requirements • Standard Weights Improve Testability with Language • Tell the tester what to do. Examples: • Clearly Defined Actions – Tester Versus System • The test has to have exact references to orient the tester. • Empty Labels in Test Cases Examples: – Delete item date:________ – Time: _______ – Item ID:________ – Tester login ID:________ Why Use Test Case Templates • Prevents Blank Page Panic • Assists the Disorganized • Builds in Standards • Prints spiffy looking tests • Assists Testers & Reviewers to Find Information • Includes Additional Fields Relating to Test Process • Ensures Same Repeatable, High Quality • Reduces Redundant Work Challenge: Requirements Changes Response: The best defense here is being informed. Before writing cases, and at every status meeting, find out where the greatest risk of requirement changes are. Strategize what cases will and won't be affected by the change. Write the ones that won't first. Build in variables or "to be decided" that you will come back and fill in later. Make sure the budget owner knows the cost of revising test cases that are already written. Quantify what it costs per case. Let project management set priorities for which cases should be written or revised. Let them see you can't do it all and ask them to decide where they have greatest risk. Release the not-quite-right test cases unrevised. Ask the testers to mark up what has to be changed. Schedule more time to test each case, plus time for maintaining the tests. Challenge: Schedule Changes Response: If a testing date is moved up, get management to participate in the options of how test cases will be affected. As in the changing requirements challenge, let them choose what they want to risk. Add staff only if time permits one to two weeks of training before they have to be productive, and only if you have someone to mentor and review their work. Shift the order of writing cases so you write those first that will be tested first. Try to stay one case ahead of the testers. You can skinny down the test cases to just a purpose, what requirement is being tested, and a setup. This is not as bad as ad hoc testing, but management should know the results are not as reliable as if the cases were complete. Schedule more time to test this kind of test case, and time to finish the case after testing. Offer to have writers do the testing and write as they go. Schedule more time for testing and finishing the writing after testing. Challenge: Staff turnover Response: New staff need an understanding of the goals, schedule, and organization of the current testing project, in writing if possible. Verbal orientations get lost in the shuffle. New staff should concentrate on knowing the business use of the software, and then on the requirements and prototypes. They may write fewer cases, but they will be right. New staff should have hands-on training in the standards, with many practical examples of how to apply it. Their work should be closely checked at first. Try to place new staff in an area of good technical fit for the cases they will be writing.