Learning Objectives

• Importance of Test Data

• Test Data Preparation
• Using BVA and EP for preparing Test Data
• Test case preparation
• Mapping Test data with the Test case

1
Testing Process

Test Strategy

Test Plan

Test Case

Test Data

Test Bed Setup

Execute Test Cases

Log Defects

Status Report

2
 Importance of data in testing
Why data is important during testing

• How do we test abnormal conditions?

• On what basis do we convey that there is a defect in the

software?

3
Test Data

• Input and/or expected files used during test execution.

• May be in the form of generated input files, usually used for

back-end testing) or information that the tester will enter
during testing (ex. password, username), which is usually
used for front-end testing.

• Should be cross-referenced in the Test Script.

4
 Test data
• Types

– Variable data : used normally in unit testing

• used in program statements

• Eg: Variable declarations, loops, conditions as counters, flags etc

– Test data close matching the real data : used during system
testing

– Real user data : used especially during UAT

5
 Test Data Creation Process
In addition to normal positive conditions, the test conditions
address the following:
1. Acceptable values : also called positive data values

2. Limit values. Values that are not within the normal range but
are acceptable.

3. Negative values. Unacceptable values. Data out of range

4. Exception values. Values that are not normal but can occur;
they need special processing (e.g., receiving an empty file as
the input).

6
 Equivalence Partitioning
• Black-box technique that divides the input domain into classes
of data from which test cases can be derived
• An ideal test case uncovers a class of errors that might require
many arbitrary test cases to be executed before a general error
is observed
• Equivalence class guidelines:
– If input condition specifies a range, one valid and two invalid
equivalence classes are defined
– If an input condition requires a specific value, one valid and two
invalid equivalence classes are defined
– If an input condition specifies a member of a set, one valid and one
invalid equivalence class is defined
– If an input condition is Boolean, one valid and one invalid
equivalence class is defined

7
 Equivalence Partitioning - Example
• Suppose a system asks for the input numbers between 100 –
999
• This gives three equivalence classes.
– <100
– 100-999
– >999
• Test the system for numbers which falls in these classes
– Any number between 0-99
– Any number between 100-999
– Any number between >999
• Typically boundary values is not considered.

8
 Boundary Value Analysis
• Black-box technique that focuses on the boundaries of the input
domain rather than its center
• BVA guidelines:
– If input condition specifies a range bounded by values a and b, test
cases should include a and b, values just above and just below a
and b
– If an input condition specifies and number of values, test cases
should exercise the minimum and maximum numbers, as well as
values just above and just below the minimum and maximum values
• Apply guidelines 1 and 2 to output conditions, test cases should
be designed to produce the minimum and maximum output
reports

9
 Boundary Value Analysis - Example
• Suppose a system asks for the input numbers between 100 –
999
• This gives two boundary values.
– 100
– 999
• Test the system for numbers which falls around these values
– 99,100,101
– 998, 999, 1000
• Typically values which falls far away from boundary values are
not considered.

10
 Questions and Comments
• What questions or comments
do you have?

11
 Test Plan
• Scope and Purpose
• Testing Strategy (Testing types/levels to be considered)
• H/w and S/w requirements
• Schedule and metrics to be collected
• Version control procedures
• Features to be tested/not to be tested
• Resources/Roles/Responsibilities
• Dependencies
• Risks and Mitigations
• Other Assumptions (If any)
• Tools to used
• Approval and Review procedures

12
Test Terminologies
Test Approach An analysis of all major aspects of the test
phase that could affect the success of that
phase
Test Scenario High level description of functionality areas that
will be tested, and are derived from the
specification that must be tested.
Test Cases A list of items that must be tested to fully test
the associated test scenario; each condition,
therefore, details a low level test and will have
a corresponding expected result

Test Cycle Sheet A matrix defining when, and by whom, test

cycles will be executed
Test Steps A detailed documentation of the exact steps
that a tester must follow to complete testing
(i.e., to test all the conditions), including the
data that will be used for testing.

13
 Test Case
• Req ID
• Test Case ID
• Test Condition/Description
• Pre-Requisite
• Test Step (Test Script)
• Test Data
• Expected Result
• Actual Result
• Status (Pass/Fail)

14
Test Condition Properties
Name and Begin these with an action verb:
description of create, print, etc.
the test Example: “Create invoice.”
condition
Expected result For each test condition, define a
corresponding expected result.
Example: “An invoice is created.”

Requirement or Each test condition is derived from

design source one requirement or design item.

15
Test Conditions: Key Considerations

1. Consider if the test data should be embedded (explicitly

specified) as part of the Test Case document.

2. Document test conditions using a table or spreadsheet.

16
 Using the TC Creation Process

1. Derive TC from Requirements (and/or Test Scenarios).

2. Trace each TC back to a specific requirement.

3. Create TC during the Design stage and refine as the project

progresses.

4. Verify that detailed functional requirements have been met.

5. Group TC logically by Test Cycle.

17
 Characteristics of Good Test Case
• Provide explicit, step-by-step instructions.
• Are highly detailed.
• Are reusable.
• Cover all Test Conditions.
• Reference necessary input data.
• Follow a standard format.
• Should provide a high degree of detail, both in the condition and
the expected result.
• Both the Assembly Test Condition and the Expected Result
should closely match the corresponding Test Scenario and
detailed Functional Requirement.

18
 Examples: Good and Bad TCs
1. Read the sample Test Conditions and Expected Results below.
2. Discuss: Which example is better? Why?

19
 Examples: Good and Bad TCs
1. Read the sample Test Conditions and Expected Results below.
2. Discuss: Which example is better? Why?

Figure 1b specifically addresses the stated requirement,

and includes all necessary criteria to ensure
that the requirement is fully satisfied.

20
 Creating Test Steps
• When does one write a test step?
– In order to enable the tester to execute specific
actions and compare actual results to expected
results.
– Immediately prior to test execution.
– After sufficient application details are gathered to
aid in the writing.
• How does one write a test step?
– Detail the exact steps that a tester must follow to
complete testing (i.e., to test all the conditions).
– Include the data that is used for testing.
– Are documented using a table or spreadsheet
format (or a test management tool).

21
 Characteristics of Good Test Step

• Provide explicit, step-by-step instructions.

• Are highly detailed.

• Are reusable.

• Cover all Test Conditions and Expected Results.

• Reference necessary input data.

• Follow a standard format.

22
Test Step Fields

Step Action / Input Data Expected Result

Number Description
1.001 Enter User First Name: XXX Page displays the
Name Last Name: XXX entered information
Middle Initial: X
1.002 Create User Password: XXX Password is displayed
Password Retype Password: as a series of asterisk
XXX (***)

The Step Number field identifies each step to be executed. When a

defect is identified, the corresponding Step Number should be
documented in the SIR.

23
Test Step Fields

Step Action / Input Data Expected Result

Number Description
1.001 Enter User First Name: XXX Page displays the
Name Last Name: XXX entered information
Middle Initial: X
1.002 Create User Password: XXX Password is displayed
Password Retype Password: as a series of asterisk
XXX (***)

The Action/Description field provides detailed directions as to HOW to

execute each step, and should be based off of the existing Test
Conditions. Each of these steps should begin with an action verb, and
should only describe one action at a time.
24
Test Step Fields

Step Action / Input Data Expected Result

Number Description
1.001 Enter User First Name: XXX Page displays the
Name Last Name: XXX entered information
Middle Initial: X
1.002 Create User Password: XXX Password is displayed
Password Retype Password: as a series of asterisk
XXX (***)

The Input Data field lists each field for which the tester should input
data to complete the Action/Description. Note that this field only lists the
type of data to be entered (hence the “XX” format); the data itself is
housed in a separate document.
25
Test Step Fields

Step Action / Input Data Expected Result

Number Description
1.001 Enter User First Name: XXX Page displays the
Name Last Name: XXX entered information
Middle Initial: X
1.002 Create User Password: XXX Password is displayed
Password Retype Password: as a series of asterisk
XXX (***)

The Expected Result field should be closely aligned with the existing
Test Conditions and Expected Results. It should explicitly describe the
result testers should see upon completing the action for that step.

26
 Test Bed setup

• Client environment and testing environment should be same

• First uninstall the previous build (if any)
• Use a separate test environment
• There must no development tools installed in test bed
• Ensure right OS and service pack installed
• Ensure right system configuration
• Ensure disks have enough space for application
• Carry out a virus check if needed

27
 Test Execution Process
• Prerequisites to Successful Test Execution
• Planning and preparation are complete
• Inspections have occurred
• Environment is well established and ready
• Test team is trained
• Migration procedures exist
• Test tools are used

• Process to Execute the Test

• Execute the test case
• Compare the actual results to the expected results
• Identify and resolve any discrepancies
• Document the results

28
 An Example - The Postal Regulation
The following postal regulation determines postage surcharges. This regulation applies only to parcels,
not other types of postal items, and only to parcels sent to South America. Other postal items are
envelopes and post cards. There is no postage surcharge for envelopes and post cards.
For parcels which people mail to South America between December 1 and December 24 of each year,
the system will apply the surcharges in Table 1 in addition to the standard postage of $5.00 US:

Table 1 - Country & Weight Surcharge between December 1 and December 24

Argentina All weights $11 US

Brazil Weight > 33 pounds $21 US
Brazil Weight = 33 pounds $19 US
Brazil Weight < 33 pounds $17 US

Columbia, Ecuador, Peru, Bolivia, Chile, French Guiana, Guyana, Paraguay,

Suriname, Uruguay, Venezuela, and Falkland Islands All weights $15 US

Analyze the given requirement and prepare possible

#Test Cases and test data
29
 Questions and Comments
• What questions or comments
do you have?

30