1. Test Case Designing UNIT - 2

2. Topics Test Requirement Analysis (example) Test Case Designing (sample discussion) Test Data Preparation (example) Test Coverage

3. Test Case Design-Objectives Objective in test case design:  Detect as many defects as possible.  Good test coverage  Minimize test development costs.  Minimize test execution costs.  Minimize test maintenance costs

4. Type Source 1.Requirement Based Specifications 2.Design based Logical system 3.Code based Code 4.Extracted Existing files or test cases 5.Extreme Limits and boundary conditions Sources

5. 1.Identify the basic cases that indicate program functionality. 2.Create a minimal set of tests to cover all inputs and outputs. 3.Breakdown complex cases into single cases. 4. Remove unnecessary or duplicate cases. 5.Review systematically and thoroughly. Steps for selecting test cases: Requirement based test cases

6. Looks for exceptional conditions, extremes, boundaries, and abnormalities. Requires experience, creativity of the Test Engineer Need: Extreme cases

7. Extracted cases involved extracting samples of real data for the testing process. Randomized cases involved using tools to generate potential data for the testing process. Extracted and Randomized cases

8. 1. Equivalence Partitioning 2. Boundary Value Analysis Test case Design methods 3. Random Testing

9. Random Testing Each software module or system has an input domain from which test input data is selected. If a tester randomly selects inputs from the domain, this is called random testing. For example, if the valid input domain for a module is all positive integers between 1 and 100, the tester using this approach would randomly, or unsystematically, select values from within that domain; for example, the values 55, 24, 3 might be chosen.

10. Equivalence class is a subset of data that is representative of a larger class Divide input domain into equivalence classes Attempt to cover classes of errors One test case per equivalence class, to reduce total number of test cases needed InputDomain Equivalence partitioning

11. A program which accepts credit limits with a given range Say, $10,000 – $15,000 This would have three equivalence classes:- 1. Less than $10,000(Invalid) 2. Between $10,000 and $15,000(Valid) 3. Greater than $15,000(Invalid) Example

12. Less than 10,000Between 10 and 15More than 15,000 9800 1250018000 Equivalence Partitions

13. Complements equivalence partitioning, selects the test cases at the “edge” of equivalence classes. In practice, more errors found at boundaries of equivalence classes than within the classes Divide input domain into equivalence classes A technique that consists of developing test cases and data that focus on the input and output boundaries of a given function Boundary Value Analysis

14. In the same credit limit example: the boundary analysis would test 1. low boundary plus or minus one ($ 9,999 and $10,001) 2. On the boundary ($10,000 and $15000) 3. Upper boundary plus or minus one ($14999 and $15001) Example

15. 1.Value immediately below range 2.First value of range 3.Second value of range 4.Value immediately below last value of range 5.Last value of range 6.Value immediately above range Range of Boundary Values

16. Based on the theory that test cases can be developed based upon the intuition and experience of the Test Engineer. In an example where one of the inputs is the date and the Test Engineer may try February 29, 2000 or 9/9/9999 Error Guessing

17. Test Case Design techniques Special value testing-  Selecting data based on the basis of the features of the function to be computed is called special value testing. This is applicable mainly to mathematical computations

18. Test Case Design-Best practice Best practice is to develop at least two test cases for each requirement for test:  a test case to demonstrate the requirement has been achieved, often referred to as a positive test case,  another test case, reflecting an unacceptable, abnormal, or unexpected condition or data, to demonstrate that the requirement is only achieved under the desired condition, referred to as a negative test cases.

19. To Capture Test Case Details: 1.Testcase ID (should be unique, eg: c_01.1, c_01.1a, c_01.2,…) 2.Feature functionality to be tested (each Requirement/feature could be from Usecase) 3.Test Description/ test input details (test input, test data, action to be performed to test the feature, complex test cases be split to more than one) 4.Expected behavior ( in messages, screens, data, to be with correct details) 5.Actual and Status