Engineer Test Data
   
Engineer Test Data  
   
Request a Needs Assessment
   
  We can:
    teach you how to do this activity
  with our in-house or
public seminars and e-learning
 
    show you how to do this activity
  with E-Coaching
    lead your experts
through this
activity in a Facilitated JRP/JAD Session
Request project evaluation

 

Return to top of this page

 
Test data engineering focuses on selecting data values that have a higher probability of identifying an error than any similar set of data values. Whether the test data comes from production files, existing tests or is created by the tester, properly engineered data reduces the number of required test cases.
     
Test data engineering
  enables you to reliably predict the expected results in sufficient detail to avoid misinterpretation of the test results
  creates data that is more likely to find errors in the solution
  is a baseline for test coverage metrics
  reduces the number of test cases needed to achieve testing goals
  exercises the system components at their boundary points
  ensures that the most likely failure causes are avoided
  establishes a baseline for repeatable tests that deliver consistent results in regression
 
         
 
 

When should you engineer test data?
   
Once business rules have been established that define data constraints, data values that test those rules should be engineered. When a data structure is defined, the data to test the structure should be engineered. Prior to starting unit, integration, system, performance, configuration, end user acceptance or any other form of testing, the appropriate data should be engineered.  
 
 

Who should engineer test data?
   
Developers need to engineer the test data they use in unit and integration testing. Quality assurance (or any other test group) should engineer the data they need for system testing. End users should engineer their data for effective acceptance testing.  
       
 
 

Foundation Training for Business Systems Analysts
   CIL710 : How to Test an Application using Business Requirements
 VIL712 : How to Find and Build Test Cases from Requirements
 

Overview Presentations for Management
 
 

Other Products and Services
   Tailored Training
 The Small Project Guide
     
 

Under Time Pressure?

  
Learn how to run an efficient, effective JAD session that does this activity faster.
How to Prepare and Facilitate Productive JRP-JAD Sessions
Our e-Coaching offer is a cost-effective alternative for small groups to learn these and other business systems analysis techniques at their own workplace or for follow-up after a training seminar

Requirements Solutions Group offers training as well as web-based and on-site consulting services to support a wide range of activities within the system development life cycle all targeted exclusively to the Business Analyst, Requirements Engineer and the Subject Matter Expert.

You can also visit our bookstore for the newest publications in the business systems analysis field.

Request a Needs Assessment
 

Test Case Identification

Sometimes the hardest thing is to get started in identifying test cases or scenarios. If you don't have any system documentation, focus on your business expertise, your imagination and your ability to ask questions.

Step 1: Brainstorm a list of business events that the target application responds to. In our example on the right we want to test an accounting application.

A business event is something that happens outside the control of your information system. It invokes a reaction from your system.

Business Event List

1.  Customer pays invoice
2.  Customer doesn't pay in time
3.  Vendor delivers goods
4.  Marketing introduces new product
5.  End of fiscal year
6.  ..........

 

Step 2: For each identified event, select variations that you want to test.

Ask yourself what strange and unusual things can happen related to the business event. These variations are your test scenarios.

Scenarios to be Tested

Event Test Scenario
1.  Customer pays invoice 1.1  Customer pays correct amount
1.2  Customer underpays amount
1.3  Customer overpays amount
1.4  .........
2.  Customer doesn't pay in time 2.1  .........
2.2  .........
3.  ........ 3.1  .........
Step 3: For each test scenario, identify the expected system response.  
  • Create "global responses".
    These are system responses that are triggered for all of the identified test scenarios.
  • Identify "test scenario specific responses"
    These are system responses that are only triggered for selected test scenarios.

Global and Specific Responses

Event Scenario Global Response Specific Response
1.  Customer pays invoice 1.1  Customer pays correct amount
 GR1.a  Update customer account
GR1.b  Post payment to ledger		 NONE
1.2  Customer underpays amount SR1.2.a  Send overdue notice
SR1.2.b  Calculate late fee
1.3  Customer overpays amount SR1.3.a  Create credit notice
SR1.3.a  Return overpaid amount
2.  Customer doesn't pay in time 2.1  ......... GR2.a  ........ SR2.1a  .........

Step 4: For each identified response, identify the appropriate test data (inputs, expected outputs and stored data values).

Equivalence class identification and boundary value analysis will identify the optimal values that need to be tested.

Identifying Data to be Tested

Global/Specific Response Impacted Data Fields
GR1.a  Update customer account INPUT: customer account#, payment amount, payment date, etc.
STORED DATA: previous amount due, current payment due date, etc.
OUTPUT: new open balance, new due date, etc.
GR1.b  Post payment to ledger INPUT:
STORED DATA:
OUTPUT:
SR1.2.a  Send overdue notice  
SR1.2.b  Calculate late fee  
SR1.3.a  .......  
 

Pieces of a Test Case

A test case is a set of input values and actions that depict a situation to which the system should react in a predictable manner.

Documentation makes test cases repeatable by people other than the person who designed them. The following table is a compilation of potential components that you can use to evaluate your test case design.
 

 
Test Case Item Definitions and Examples
Test Case ID A unique identifier for each test case
Test Case Description A name or short sentence describing what this test case does
Purpose of the Test A short answer to the question, "Why is this test needed?"
Resources Required List of all resources (e.g. hardware, software, people, training, testing tools) needed and why (role of the resource)
Reaction to Defects Specific description of how the project team will react to reported discrepancies between expected and actual results
Risk Category Required to minimize the number of test cases
Interfacing Systems List of all systems that provide information to or receive information from the system in which the test is executed for this set of tests
Prerequisite Test Cases List of test cases that must be successfully completed prior to executing this test case
Required Data Content Data content that is required for test execution (set up requirements)
Estimated Effort Amount of work time required to execute the set of test cases
Expected Duration Amount of calendar time required to execute the set of test cases
Set up Steps Audience-level detailed instructions for setup of the test
Execution Steps Audience-level detailed instructions for execution of the test
Evaluation Steps Audience-level detailed instructions for evaluation of the test results
Expected Result Verifiable result that should be achieved when this test is executed
Execution Date/time Date and time the test was executed
Executor ID Name of the person executing the test
Actual Result Actual result achieved if it is different than the expected result
Actual Effort Amount of work time that was required to execute the test
Actual Duration Amount of calendar time that was required to execute the test
Test Run Status Indicates whether test was completed, interrupted, passed or failed.