Test Case Designing

UNIT - 2

Topics

Test Requirement Analysis (example) Test Case Designing (sample

discussion) Test Data Preparation (example) Test Coverage

Test Case Design-Objectives Objective in test case design:

Detect as many defects as possible.Good test coverageMinimize test development costs.Minimize test execution costs.Minimize test maintenance costs

Type Source

1.Requirement Based Specifications2.Design based Logical system3.Code based Code4.Extracted Existing files or test cases5.Extreme Limits and boundary conditions

Sources

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

• Looks for exceptional conditions, extremes, boundaries, and abnormalities.

• Requires experience, creativity of the Test Engineer

Need:

Extreme cases

• 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

1. Equivalence Partitioning

2. Boundary Value Analysis

Test case Design methods

3. Random Testing

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.

• 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

InputInputDomainDomain

Equivalence partitioning

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

Less than 10,000 Between 10 and 15 More than 15,000

9800 12500 18000

Equivalence Partitions

• 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

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

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

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

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

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.

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