How To Build and Execute A Test Case - Procedure

How to Build and Execute a
Test Case/Procedure
Process Work Instruction
Revision 1.0
December 13, 2006
How to Build and Execute a Test Case/Procedure
Approvals
Document Owner
Date Approved:
Process Manager
Date Approved:
13 December 2006
II
Revision History
Release Date
Version
Change Summary
December 13, 2006
1.0
Initial Draft
13 December 2006
III
Table of Contents
1
2
3
Purpose .............................................................................................................................................. 1
Scope .................................................................................................................................................. 2
Process ............................................................................................................................................... 3
3.1
Process Flow ............................................................................................................................. 3
3.2
Roles and Responsibilities ...................................................................................................... 3
4 Instruction ........................................................................................................................................ 4
4.1
Test Engineer Defines Scenario(s) ......................................................................................... 4
4.2
Test Engineer Defines actions, characters and variables .................................................... 5
4.3
Test Engineer Defines Expected Output............................................................................... 9
4.4
Test Engineer Generates Data .............................................................................................. 10
4.5
Test Engineer Resets System or Component Being Tested to a Known State............... 11
4.6
Test Engineer Submits or Processes the Transactional Data ........................................... 11
4.7
Test Engineer Monitors Processes ....................................................................................... 11
4.8
Test Engineer Retrieves Results ........................................................................................... 12
4.9
Test Engineer Validates Output ........................................................................................... 12
4.10 Test Engineer Reviews and Analyzes Results ................................................................... 12
5 Reference Documents................................................................................................................... 13
Appendix A: Acronyms, Abbreviations & Definitions ........................................................... A-1
Appendix B: Tools .......................................................................................................................... B-1
List of Figures
Figure 3-1 Process Flow........................................................................................................................... 3
List of Tables
Table 3-1 Roles & Responsibilities ......................................................................................................... 3
Table 4-1 Actions, Characters and Variables ....................................................................................... 6
Table 5-1 Reference Documents ........................................................................................................... 13
Table A-1 Acronyms, Abbreviations & Definitions ........................................................................ A-1
Table B-1 Tools ..................................................................................................................................... B-1
Table B-2 Configuration Data............................................................................................................. B-1
Table B-3 Transactional Data .............................................................................................................. B-1
Table B-4 Expected Output ................................................................................................................. B-2
13 December 2006
IV
This page intentionally left blank.
13 December 2006
Purpose
In this process work instruction we explain how to define and create test case(s)/scenario(s) for a fictitious reporting system. We will execute the following procedure in order to generate all of the information needed by a test engineer to perform the steps involved in creating and executing a test
case(s)/scenario(s).
Define Scenario(s)
Define actions, characters and variables
Define expected output
Generate Data
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
13 December 2006
Scope
All of these steps are of primary importance to the test engineer during the testing phase of any project.
13 December 2006
Process
3.1
Process Flow
Figure 3-1 Process Flow
3.2
Roles and Responsibilities

Role
Responsibility
Test Engineer
13 December 2006
Defines, documents, analyzes, performs, and interprets developmental 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.
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.
Table 3-1 Roles & Responsibilities
Instruction
The pre-requisites to the task of creating a test case/procedure include having a diagram or explanation
of the business process. The business process is then used as the basis to determine what and how software was used in order to automate all or some parts of the process. It is the test engineers responsibility to make sure that they have a rudimentary understanding of the process or processes that are being
automated.
The business process is critical to the examination and explanation of what the system does or should do
according to business rules as defined. In our example we are building a reporting system and it is a
pretty basic component of a business system these days. We go on to say in the scenarios that the reporting system provides data about the companies doing research. Since this is a fictitious system we
have no real reference to work from but it would be my first choice as a test engineer to understand the
basics of the system that is or has been implemented. There are many ways to automate a business process but no matter the tools or the architecture the basic premise is that you can either build it or buy it.
If a decision was made to purchase a COTS product as the basis for the reporting system you will probably have access and want to read or examine the COTS users guide in order to get a fundamental understanding of its capabilities. In addition, you may also need to understand the configuration and transactional elements and where they are stored. In most systems, configuration elements are stored locally
as text, xml or config files and transactional elements are usually kept within a relational database of
some sort. It is a good idea for the test engineer to have a basic working understanding of the configuration and or transactional elements and where they can be found because you may need this information
for use in verifying results as we will discuss later.
If you have undertaken a development effort then the rules change a little but the goal is the same to get
an understanding of the configuration and transactional elements of the system. This data may come
from many places including architecture, engineering documentation; it may even have to come directly
from the software engineers who developed the custom system. Unless you have a thorough engineering
process developed and the time to create, design and document the system you will probably find that a
lot of details around configuration and transactional elements were decided by software. These decisions
directly affect how you the test engineer will test and validate a particular scenario or case. For instance
if you have one developer who liked to use xml files as the basis for his configuration and you have another who has used the database you will need to know what and where these files are in order to verify
or configure the system for your tests. Now I am not saying that this is normal but in some cases this
may be the only means by which you can gather the information that you need in order to accomplish
your goal which is to create a test case/procedure. I guess all I can recommend is that you start early in
the process and you try to gain as much knowledge about the system as you can before you delve into
writing a test case or procedure.
Since we have only been asked to test the reporting system, the example and instructions that follow only review creating procedures for it. We are not testing any hardware or cots products, we would hope
that these elements have been installed and configured properly so that we can get to work creating and
writing our test case procedure. Once you have spent some time understanding the process, system and
components you are now ready to create the test cases/procedures that will be used to prove that the
software that automates the business process is working according to its requirements
4.1
Test Engineer Defines Scenario(s)
Wikipedias Definition of Scenario:

In computing, a scenario is a narrative describing foreseeable interactions of types of users (characters)
13 December 2006
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.
Primary Example
A clearly written scenario will help you to clearly define the process and interactions between systems
or components. For instance, we have 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.
Secondary Example
The reporting sub-system is an HTML reporting tool that allows the user to define characteristics (parameters) that are used to filter data. This filtered data is then formatted according to a pre-defined format (user-selected) and presented to the user. Once presented the user has the ability to Save-As (html,
txt or .pdf formats are available) or print the report to a printer. The sub-system must be able to accept
input via an HTML form and submit the form via an HTML POST to the reporting subsystem. The reporting sub-system will accept report name, parameter list (delineated by ~) as defined by the individual
report, the users name and password if appropriate.
4.2
Test Engineer Defines actions, characters and variables
The first step in defining the actions, characters and variables is to break down the scenario into its sentence parts. For our reporting system example above, you might break down the scenario as follows:
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
Select a specific report
Enter/Update the parameters
Print the report
Save the report
During the process of defining and categorizing data elements it is handy to know or have documented
what the system provides or stores for a particular transaction and the configuration options and there
13 December 2006
meaning. Most of this information will need to be gleaned from the requirements if this is new development or the users/setup guide if using an existing or Commercial Off-The-Shelf (COTS) product.
After breaking apart the sentence and reducing the list down to its sentence parts you can then begin developing the list of actions, characters and variables. This list should include both configuration and
transactional elements that have been defined by either the requirements or the user/guide. I have broken
down the primary example into the following:
Action: provide
Characters: system and user smith
Variables: project name, dollar amount, number of personnel, time and number captured.
Action: look up
Variables: set of criteria

Action: use
Variables: project name, dollar amount #

of personnel
Action: allow
Variables: username, password
Characters: system and smith

Action: select
Variables: menu selections

Action: enter/update
Variables: project name, dollar amount and

number of personnel
Action: print
Variables: printer name, printer options
Characters: system, smith, printer
(we probably are not testing the printer but we

might want to add a few variables such as portrait vs landscape to see how the report might
look if the user makes a mistake. Useful mostly
for operations rather than testing)
Action: save
Variables: file name, file location, file type
Characters: system, smith

Table 4-1 Actions, Characters and Variables
If this is a new development project and you find holes in requirements during your analysis make sure
that you provide this information back to those writing the requirements as they may want to address or
add in what you find. If this is a cots product or existing development you must rely on the setup, configuration, actual users and possible the users guide or other available resources to help in the definition.
In our primary example, the data elements that might be typical include user name, password, report
name, date and time the report was last executed, who executed the last report, how long the last report
took to execute, the project name, dollar amount and # of personnel. Depending on what the original requirements were for the reporting tool this could be a significant list of possibilities. All of the data referred to can be chosen and/or inputed at the time of report submission so it must be carried in the transactional data.
13 December 2006
After defining the actions, characters and variables you will probably have some questions. Some questions that may be asked are:
What specific information is in the reports
What kind of research does the information cover
What companies are listed
How does the data get into the system
How many updates are done per week, etc.
This information is all important to providing a thorough understanding of the system that will be tested.
To simplify our example, the only data captured and available about the research is project name, dollar
amount and number of personnel. It is captured daily for any new projects, and the average is about 3 to
5 new projects each day.
List and Categorize the variables according to Configuration or Transactional
After defining the actions, characters and variables list and categorize the variables into two types: Configuration and Transactional. You will probably have a variable be both configuration and transactional
so make sure that you list it twice. This exercise gives you a more complete picture of the type of data
that you will need to define in order to configure and execute the system that you are about to test.
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
Define Semantic for Transactional Data

We cannot test every possible combination for a given scenario unless the possible combinations are
very limited. With this in mind, we have to be able to test as many different combinations as possible to
reduce risk that a particular data set will have unexpected results. We define a specific set of possible
combinations using both configuration and transactional variables. This combination will include as
many test data sets as deemed needed for a particular scenario.
The preference is usually to define not less than ten and not more than twenty-five test data sets. If you
have more than twenty-five data sets you will need to sub-divide the system into its components and
begin the process over again. If you have less than ten then you probably are not providing sufficient
coverage of the applications capabilities.
In order to define the transactional data for our primary example we need to provide a number of data
13 December 2006
combinations. The User Smith, in our scenario, can have a finite number of reports. We can start defining the semantic for the transactional data by determining the possible parameters for each report.
Depending on how the parameters were defined we may or may not have a finite set. If the variables
used for the parameters are within a lookup then it will be finite. If the variables are defined as text or
entry fields then we must rely on and understand what validation has been imposed on the set of fields
that are being used with the report in order to define the testing impact.
We will be using the following semantic to define our test case: 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.
Parameter three, number of personnel is between 1 and 1 million.
We will need to define sets of data that test the boundaries of the validation that we have defined above.
We will be validating using a random set of data that is generated for each data type. When defining the
semantic it does not really need to be known what type of generation technique is used, but I have found
that randomly generating data for each known type provides that most coverage overall of the capabilities and validation that is in place for a specific value.
Our semantic will therefore include the following data variables Report Name, Parameter 1, Parameter
2, Parameter 3 that need to be defined for each of the test sets that we will need to generate.
After specifying the semantic for the transactional data, we will begin defining what configuration data
needs to be in place in order to execute the test.
Specify Configuration Data
All systems use pre-defined (configuration) data in order to support specific capabilities, we will need to
define how a particular system function is implemented and what variable data needs to be defined in
order to test the specific capability. Preparation of a particular configuration usually involves specifying
any system or user defined variables that are used.
In the case of our fictitious reporting system, we will define some of the configuration variables that exist. The max number of reports for a given user is five and each user can have up to five parameters for
each report. In order to define a report we must define both a short name and a long name and the reports are categorized within the following groups: Sales, Engineering, Support or Customer. User Smith
is part of the Engineering group and uses this report daily, so the report will be classified as an Engineering Report. With the previous example we can now specify the configuration as
User: Smith
Report Number: 1
Short Name: Smith Daily Project Report
Long Name: This report is used to see if any new projects have been added since the last report
was completed and provides a list of current projects.
13 December 2006
Category: Engineering
Report Parameter 1: Project name
Report Parameter 2: Dollar Amount
Report Parameter 3: Number of Personnel
Report Parameter 4: N/A
Report Parameter 5: N/A
In addition to the configuration data of the system, we also will need to populate the transactional data to
a known state in order to provide for our expected results. The following records have been defined
within the system as transactions that we will use to exercise or reporting system. See Table B-1 Configuration Data.
Specify Transactional Data
We could test every possible combination of data that could be used as input to the report but this would
take too long and not be very cost effective, so we must select a subset of the data to test with. We define that we will as an example, exercise the Smith Daily Project Report with the following possible
combinations of input:
These are not all the possible tests that can be performed but will give you an idea of the number of
combinations and complexity that defining too many possibilities can lead to.
It has also been helpful when defining a large number of parameters to produce groups of possible data
combinations. For instance, if you know that you need to have an address, you might want to create possible address combinations like (1234 lane), (44 dover drive) or (&4# d8sdafh drive etc) After creating the combinations of data, you can then generate a certain # of transactions with random selections
from each of the groups of inputs. This has been very helpful when automating a specific test case or
case(s).
Now that we have determined our semantic for our data set, what the configuration data should be and
our test data sets we need to define our expected outcome for each of the test sets. See Table B-2 Transactional Data.
4.3
Test Engineer Defines Expected Output
With our new transaction data, setup transactions and setup configuration defined we can define what
we expect as our output from processing. Because we have defined both the configuration and existing
transaction data, we can base our expected output on our understanding of the capability of the system.
The actual steps involved in executing a report will be defined later with the submission or processing
definition.
In defining the expected output, we begin with the capabilities that the system is providing. As this definition has already been provided by the actions of the system, and include Provide, Look up, Use, Allow, Select, Enter/Update, Print and Save the report output, we can define that our expected output is
what we expect to see happen after each action. We will go through each action individually and possibly re-sequence the events to happen as they would if we were actually sitting at a keyboard.
We usually start with the first character in our scenario, which in the primary example is User Smith. So
putting the actions in order, we would probably Allow User Smith to login to the system, then Select a
specific report, Use the following as parameters to the report: project name, dollar amount and # of personnel, Enter/Update the parameters. The System character would then Look up information related to
the companies, based on a set of criteria and Provide data to User Smith about companies that do re13 December 2006
search. Then User Smith would in turn, Print the report and/or Save the report. Now that we have the
right sequence of events we can define what our expected configuration and transactional input and output should be for each event. See Table B-3 Expected Output.
Now that the actions, input and expected output have been defined, we can generate our data set for each
test case that we want examined. This input should result in the expected output as defined for each test
case.
4.4
Test Engineer Generates Data
Going back to our action list, we need to examine each action again, this time taking into account the
data sets that we have specified and what data needs to be configured for each. Once specified, we will
then detail the output that we are expecting. For our first action, we will need our fictitious system installed and in basic working order (Integration). After the basic integration is completed and in place, we
can define the following for the known state or initial configuration of the system:
Configuration Data
After initial integration and configuration you will create the following in our fictitious reporting system
to get it ready to accept transactional data.
A username and password for User Smith.

The categories Sales, Engineering, Support or Customer have been defined.
A report has been defined with the short name Smith Daily Project Report and login name: This
report is used to see if any new projects have been added since the last report was completed and
provides a list of current projects. The category of the report is engineering and the three parameters are project name, dollar amount and number of personnel
Once the integration and configuration data has been put into place, make a backup copy of the entire
system in its current state so that it can be brought back or reset to this state at any time. You will probably be resetting the data set to its configuration state many times and possible changing and updating
this configuration information and taking additional backups. It would be prudent to have this information readily available, documented and automated at the earliest possible time. This can be a time
consuming task but the end result is well worth the time spent in advance to get this into place.
Transactional Data
This step involves the generation or creation of the data for the test sets that you have specified. With
our small example reporting system we have generated the data within this document so there is no reason to create any additional data sets but if you have a more elaborate system you may want to think
about options to generate test data. Some options that are available include:
Creating the data by hand (always an option but tedious and time consuming)
Buying a third party product that generates test data (sometimes limiting need to train)
Creating and Generation data groups from multiple sources (this option can be easily generated
with data captured from multiple sources on the internet including, surnames, first names female,
first names male, address combinations etc)
Automating the entire process of Creation, Submission, Monitoring, Retrieving results and Validating Output. (this is probably the most time consuming and in some ways reflects possibly all
of the previous options combined) In addition, this can also be the most flexible option but will
be tied directly to the system that you are building or COTS product that you are testing.
No matter how you create your data, by hand or full automation, remember that each system is different
and you have different skill sets that are available to you both inside and outside your team.
13 December 2006
10
4.5
Test Engineer Resets System or Component Being Tested to a Known

State
In order to provide for a known state of any system it is necessary to reset it to a previously defined
baseline. As getting any system to a known initial state is a time consuming task, it is important to remember that once accomplished, you can reuse and expand the configuration to accommodate any tests
that you may need to create and execute. During initial testing cycles this can be a time-consuming process of repeatedly submission, monitoring, retrieving results and validating output, but this process will
help to define and mold your understanding of the system. As smaller nuances in the system arise they
can be readily documented and provided to operations so that as things occur they can be adjusted or
configured to operate properly.
After the system has been reset to its initial integration state you should apply any new or updated configuration changes. These configuration changes will include configuration information and initial state
transactional data for the test sets that you will be implementing. Once these configuration changes have
been made accordingly, you can then make an additional backup and begin the submission process of
the newly created transactional data.
4.6
Test Engineer Submits or Processes the Transactional Data
Again going back to the actions that we have created in the previous sections, we begin the submission
preprocessing of the transactional data by reviewing the actions that we have identified.
Allow User Smith to login to the system
Use the following as parameters to the report: project name, dollar amount and # of personnel
Enter/Update the parameters
Look up information related to the companies based on a set of criteria
Provide data to User Smith about companies that do research
Print the report
Save the report
For each input into the system we should follow along each action providing input specified and either
manually or automatically capture the result. Once captured, the results should be analyzed to make sure
that our results match with what we expected. If not, we will need to review our process and update the
system, our process, configuration or transaction data to accommodate any unexpected results.
4.7
Test Engineer Monitors Processes
During the processing of data almost every system leaves traces of its processing. Some are in the form
of database entries, others use logs. Whatever the system uses we should be able to monitor that each
process within the system is being properly executed.
With our fictitious reporting system we can pretend that each report, as it is processed, is logged to the
file processedreports.log in some directory on the system. So either after or during the processing of our
transactions we would want to review and possibly monitor this log. If we have issues or errors, the log
will be able to tell use what is wrong or incomplete and this will possibly lead to software updates, test
procedure updates and/or configuration updates in order to get the expected results.
In our example reporting system and our processedreports.log a capabilitiy exists within the system that
13 December 2006
11
when a report is executed for a particular user it is writing out. So while we are executing the first couple of tests, we are reviewing the log and finding that the user admin is being written for every report
that is being executed no matter who is logged in. According to our process, if it existed we have defined that the users executing the report will be logged. This problem would be reported and a patch
would be created in order to bring the system into compliance with the expected results.
Remember that during testing, expected results are what we are verifying against and expected results
should be what we assume the system should do with input from requirements and development. If our
assumptions or input is incorrect, then we may have incorrect results and these results may need to be
reviewed and updated requirements will need to be provided. In some cases, an entire review of the engineering effort may be needed after the new requirements are reviewed.
4.8
Test Engineer Retrieves Results
Results should be collected and stored so that the output can be validated against previous or expected
results and any un-expected outcomes should be collected, identified and a problem report written.
When providing input to problem reports, make sure to include the error, the logs, any configuration data and transactional data that may help in recreating the issue.
With complicated systems, the retrieving of results may be automated and collected to a point that will
then need to be evaluated further for any inconsistencies. Retrieving results is basically the collection
and storage of results for a specified execution. All executed runs should be accounted for after an initial
baseline is completed.
4.9
Test Engineer Validates Output
Once the output has been collected, it will need to be validated against previous results and the expected
results in order show that the functions or capabilities of the system are operating normally or within the
expected result range.
4.10
Test Engineer Reviews and Analyzes Results
After each validation, the results should be analyzed and reviewed for any inconsistencies. This review
and any anomalies should be documented along with the results so that it can later be reviewed and updated as needs arise.
The exact output and needs for analysis need to be planned and evaluated early in the testing cycle so
that you can just record and analyze results instead of scrambling to evaluate what needs to be captured
and how. By using this method of creating test case(s)/procedure(s) you should be able to evaluate early
what output to collect, validate and analyze.
13 December 2006
12
Reference Documents
Printed versions of these reference documents may not be current. Users must verify date and revision
levels against the current approved versions stored in the applicable
Document Number
Document Title
n/a
n/a
Table 5-1 Reference Documents
13 December 2006
13
This page intentionally left blank.
13 December 2006
14
Appendix A:
Acronyms, Abbreviations & Definitions

Acronym/Term
Definition
COTS
Commercial Off-The-Shelf
HTML
Hyper Text Markup Language
POST
Power On Shelf Test
Table A-1 Acronyms, Abbreviations & Definitions
13 December 2006
A-1
Appendix B:
Tools
Tools
Table B-1 Tools
B.1.
Configuration Data
#
Project Name
Dollar Amount
Num of Personnel
Project 1
100
AaaBbbCcc
40
123456
20
99//--++--
15
10
%&*(*&*&(&
30
Test Project 1
50
Test Project 2
500
200
Test Project 3
200
500
Test Project 4
1000
1000000
10
Test Project 5
1000000
1000000
Table B-2 Configuration Data
B.2.
Transactional Data
#
Report Name
Param 1
Param2
Param3
Description
Smith Daily Project Report
AaaBbbCcc
Valid report other
*.*
Min valid entry with

invalid param
^&*%$#
Min parameters
123456
1000000
Max min parameters
/_jdn888&%
1000000
1000000
Max max parameters
99//--++--
Random
*.
1000
1000
Random
%.*
100
100
Random
****
1000000
Max min parameters
10
%&*(*&*&(&
1000000
1000000
Max max parameters
Table B-3 Transactional Data
13 December 2006
B-1
B.3.
Expected Output
Action
Input
Expected Output
Allow user Smith to login to

the system.
Username
Password
The systems menu screen

should appear.
The Report Name
The system menu screen

should appear
Use the following as parameters to the report: project

name, dollar amount and # of
personnel, Enter/Update the
parameters
Enter project name,

dollar amount and
number of personnel
as selection criteria
for each data set created
The system will generate a

waiting screen while the report is being processed by the
system
Look up information related to

the companies based on a set
of criteria and Provide data to
user Smith about companies
that do research
Report Name, Parameters, Username

and Password will be
passed to the system.
The system will respond with

a pre-defined report with the
data expected for each of the
input parameters.
After the report has been returned to the user, the user
will be able to Print the report.
Select a printer.
The report will be printed to

the specified printer.
After the report has been returned to the user, the user
will be able to Save the report.
Report has been presented to the user.
The user will be presented

with a dialog box.
The user will enter parameters for the system to save the
report
Filename, Location
and Type of report
The system will save the

specified filename at the location and in the format that was
specified as input.
Table B-4 Expected Output
13 December 2006
B-2

How To Build and Execute A Test Case - Procedure

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

How To Build and Execute A Test Case - Procedure

Caricato da

Copyright:

Formati disponibili

How to Build and Execute a

December 13, 2006

How to Build and Execute a Test Case/Procedure

How to Build and Execute a Test Case/Procedure

December 13, 2006

How to Build and Execute a Test Case/Procedure

How to Build and Execute a Test Case/Procedure

This page intentionally left blank.

How to Build and Execute a Test Case/Procedure

Define actions, characters and variables

Define expected output

Reset System or Component being tested to a known state.

Processing and executing the actions

Reviewing and Analyzing Results

How to Build and Execute a Test Case/Procedure

How to Build and Execute a Test Case/Procedure

Figure 3-1 Process Flow

Roles and Responsibilities

How to Build and Execute a Test Case/Procedure

Test Engineer Defines Scenario(s)

Wikipedias Definition of Scenario:

How to Build and Execute a Test Case/Procedure

Test Engineer Defines actions, characters and variables

How to Build and Execute a Test Case/Procedure

Variables: set of criteria

Characters: system and user smith

Variables: project name, dollar amount #

Variables: username, password

Characters: system and smith

Variables: menu selections

Characters: system and smith

Variables: project name, dollar amount and

Variables: printer name, printer options

Characters: system, smith, printer

(we probably are not testing the printer but we

Variables: file name, file location, file type

Characters: system, smith

How to Build and Execute a Test Case/Procedure

What specific information is in the reports

What kind of research does the information cover

What companies are listed

How does the data get into the system

How many updates are done per week, etc.

T-Number of projects captured

Define Semantic for Transactional Data

How to Build and Execute a Test Case/Procedure

How to Build and Execute a Test Case/Procedure

Test Engineer Defines Expected Output

How to Build and Execute a Test Case/Procedure

Test Engineer Generates Data

A username and password for User Smith.

How to Build and Execute a Test Case/Procedure

Test Engineer Resets System or Component Being Tested to a Known

Test Engineer Submits or Processes the Transactional Data

Test Engineer Monitors Processes

How to Build and Execute a Test Case/Procedure

Test Engineer Retrieves Results

Test Engineer Validates Output

Test Engineer Reviews and Analyzes Results

How to Build and Execute a Test Case/Procedure

Table 5-1 Reference Documents

How to Build and Execute a Test Case/Procedure

This page intentionally left blank.