Building and Executing a

Test Case
By Tony L. Howard, PMP

 In the accompanying instructional document How to

create a test case, we explain how to Build and Execute
test case(s)/scenario(s).
We will build a sample scenario that provides for a
fictitious reporting system.
Once the data has been generated we continue steps to
execute the test case(s)/scenario(s).

Purpose

Role

Responsibility
Defines, documents, analyzes, performs, and interprets development tests
for new and/or modified products, product components, or systems.
Ensures that defects are reported, fixed and retested.
Participates in the development of test strategies and interpretation of test
results.

Test Engineer

Authoring of test plans and reports to industry standard specifications.

Investigates and resolves operational problems in conjunction with other
engineering and technical personnel.
Provides Technical support and advice to other departments.
Participates in the development, maintenance, and refinement of internal
quality control and reliability programs

Roles and
Responsibilities

 Building Activities

Define Scenario(s)
Define actions, characters and variables
Define expected output
Generate Data

Execution Activities

Reset System or Component being tested to a known state.

Processing and executing the actions
Monitoring Processes
Retrieving Results
Validate Output
Reviewing and Analyzing Results

Building and Executing a

Test Case.

Wikipedias Definition of Scenario:

In computing, a scenario is a narrative describing foreseeable
interactions of types of users (characters) and the system or between two
software components. Scenarios are often used in usability research.
They include information about goals, expectations, actions and
reactions. Scenarios are neither predictions nor forecasts.
In usability research scenarios are used to describe the situation in which
a certain appliance can be used. It is a practical description, written in
plain language without any technical descriptions that allows normal
users to understand them and confirm if they describe a real situation.
Scenarios are often used in usability tests to describe the task to the user
that is going to perform the test.

Defining a Scenario

 XYZ Company has a new system that provides data to User Smith about
companies that do research. Smith wants to be able to look up information
related to the research companies, based on a set of criteria that he has
defined as project name, dollar amount and # of personnel on the project. In
this simplified example, we will want User Smith to be able to log into the
system, select a specified report, update the parameters for the report and be
able to print and/or save the report to Smiths desktop for later review.
This scenario is written in terms that the user can understand so that the user
can verify the scenario prior to us moving on to defining data elements. This
same approach can be applied to a sub-component of the system by writing
the scenario(s) in terms of the audience. In the case of a sub-component, we
might have the following scenario written to inform the test engineer of the
tools capability.

Primary Example

 Primary Example
Provide data to User Smith about companies that do
research
Look up information related to the companies based on a
set of criteria
Use the following as parameters to the report: project
name, dollar amount and # of personnel
Allow User Smith to login into the system

Define Actions,
Characters and Variables

Action: provide
Characters: system and user smith

Variables: project name, dollar amount,

number of personnel, time and number
captured.

Action: look up
Characters: system and user smith

Variables: set of criteria

Action: use
Characters: system and user smith

Variables: project name, dollar amount #

of personnel

Action: allow
Characters: system and smith

Variables: username, password

Actions, Characters and

Variables

C-Menu selection (Report Name)

T-Number of personnel

C-Password

T-Number of projects captured

C-Username

T-Password

T-Dollar amount

T-Printer Name

T-File Location

T-Printer options

T-File Type

T-Project name

T-Filename

T-Time captured

T-Menu selection

T-Username

Actions, Characters and

Variables:
Configuration and Transactional

 Report Name, Parameter 1, Parameter 2, Parameter 3.

Since report name has been defined by a lookup, we have a finite list. If this list
is a selectable parameter at the time of parameter entry, we only have to exercise
the possible data set included in the list. In our case we have specified the report
Smith Daily Project Report and it is the only selection that we can make.
Parameter one, project name, is a text entry field and can include any characters
and uses (*) asterisk as the only variable that can be included within the text
field. We should include special characters and asterisks as part of our input in
order to test as many cases as needed.
Parameter two, the dollar amount is in units of 1000 and cannot exceed 1 billion
dollars.

Actions, Characters and

Variables:
Define Semantic Topology

 Specify Configuration Data

User; Report, Short Name, Long Name, Category, Report
Parameter 1 5;

Specify Transactional Data

Report Name, Parameter 1, Parameter 2, Parameter 3

Actions, Characters and

Variables:
Specific Configuration and Transactional Data

Test Engineer Defines

Expected Output

Test Engineer Generates

Data
Configuration Data

Test Engineer Generates

Data
Transaction Data

 Test Engineer Resets System or Component Being Tested

to a Known State
Test Engineer Submits or Processes the Transactional
Data
Test Engineer Monitors Processes
Test Engineer Validates Output
Test Engineer Reviews and Analyzes Results

Repeatable Activities