Test Requirements:

The Basis of Testing

1
Test Requirements

 What exactly is a Test

Requirement?
 Why identify Test Requirements?
 Where does a Test Requirement
come from?
2

Defining TR’s: What, Why, Where

What exactly is a Test Requirement?

 Identifies the “WHAT” of testing

 What needs to be tested, AND
 What are you going to validate about it

 Includes both normal and error conditions

 Covers business rules, functionality, non-functional standards
 Do NOT have case specific data values assigned to them yet (data
appears in test cases, the “How” of testing) examples…

Defining TR’s: What, Why, Where

 Example 1: Testing the inserting of a
record to a table
Test Requirements Identified (among others):
“Validate that you can insert an entry”
“Validate that insertion fails if entry already present”
“Validate that insertion fails if table already full”
“Validate that you can insert an entry to an empty table (initial)”

 These are test requirements NOT tests because they do

not describe the data element being inserted
 The data is irrelevant at this level, it will appear in the
test cases used to cover these test requirements
 “Validate you can insert ‘John Doe’” is a test case not a
test requirement
4

Defining TR’s: What, Why, Where

 Why identify Test Requirements?
 It’s what QC “owns” in our workbench:
Requirements-based or Function-based testing
 It’s the basis for establishing the completion of
testing
 Helps determine the scale of the testing effort
 Governs the types of resources you will need
 Serves to identify automation strategies you can use
 Becomes a roadmap for your testing effort
 Can be a tool for leverage and dialog with
developers and business analysts
 Dev Team can sign off on them (Verification!)
5

Defining TR’s: What, Why, Where

 Where does a TR come from?
 Traditional: Business Requirements, functionality, internal logic…
 Marketing specs, Functional specs, Technical specs
 Reality:
 “Interview Analysis”, Non-Functional Checklists (standards & compliance), Use
Cases (from business scenarios and users), Discovery during testing, any other
deliverables from previous workbenches (diagrams, modeling, flowcharts, etc.)

Defining TR’s: What, Why, Where

 How do Test Requirements
relate to the Test Plan?
 Traditionally, the Test Plan has represented “what”
was going to be tested, even including test cases.
 Paradigm is shifting: Test Plan should relate what
your testing process (and deliverables) will be for a
particular project.
 A Test Plan should build confidence in the testing
process for a project, making approaches clear.
 A Test Plan can include the Test Requirements
 However, if the Test Requirements are too lengthy,
they should become their own document: A Test
Requirements Hierarchy 7

Defining TR’s: What, Why, Where

Drilling down: Where test
requirements fit into the picture
Business
Requirement
1

Test
Generates M Requirement
1

Test
Scenarios/ M Executes/Runs
Generates M Cases 1

Test
Procedure/
Script
8

Fitting TR’s into the testing picture

Drilling Down

First, Let’s look

Business at this relationship:
Requirement What’s within our
testing process

Test
Requirement

Test
Scenarios/
Then we’ll look Cases
at this relationship: Test
Gernerating TR’s Procedure/
from what feeds into Script
our testing process 9

Fitting TR’s into the testing picture

 ATM Example: Practice
Writing Test Requirements
Business Requirements: Group Exercise!

1. Limit the scope to

- “ATM must do withdrawals” these 3 requirements.
- “Withdrawals are between
$20-$300”
2. What will you validate
(test for)?
- “Withdrawals are in $20
multiples” 3. Are there any implied
requirements that may
not be written out?
10

What’s within our testing process

 Example 2: Testing Withdrawals on an ATM
Test Requirements Identified (among others):
“Validate that a withdrawal option is available”
"Validate that a withdrawal of a multiple of $20, between $20-$300 can be done"
"Validate that <$20 is not allowed"
"Validate that >$300 is not allowed"
"Validate that $20 multiples >$300 is not allowed"
"Validate that non-$20 multiples between $20-$300 not allowed"
"Validate strange numeric amounts/combinations not allowed (all zero's, all 9's, 20.0000)"
“Validate that the withdrawal received is equal to the amount requested”
"Validate that a valid withdrawal amount must be below the account balance”

 These are test requirements NOT tests because they do not describe the
data element being used (like $20, $40, $60, $1)
 The data is irrelevant at this level, it will appear in the test cases used
to cover these test requirements
11

What’s within our testing process

 Test Scenarios/Cases for -
“Validate that a withdrawal of a multiple of $20,
between $20-$300 can be done”

Case # P/F $ entered Expected Actual

Results Results
WD01 Pass 20 $20 withdrawn
WD02 Pass 40 $40 withdrawn
WD03 Pass 60 $60 withdrawn
WD04 Pass 80 $80 withdrawn
WD05 Pass 100 $100 withdrawn
: : : :
WD13 Pass 260 $260 withdrawn
WD14 Pass 280 $280 withdrawn
WD15 Pass 300 $300 withdrawn

12 What’s within our testing process

 Test Procedure & Script for previous example
Procedure: Script: (in pseudo-code )
Step 1: Insert Card Do until EOF ‘until end of data file
Step 2: Enter PIN Input data record
Step 3: Select Withdraw option Senddata CARDINFO to “Cardfield”
Step 4: Enter dollar amount Senddata “Enter”
Step 5: Validate amount Senddata PIN to “PINFfield”
received
Senddata “Enter”
Senddata “W” to “SelectionField”
Senddata AMOUNT to “DollarField”
Senddata “Enter”
If ErrorMsg > 0 then print ErrorMsg
Print “DollarAMTgiven”
Loop
13

What’s within our testing process

When creating Test Requirements (“Do”)...
 Use “action” verbs & words
- “Validate that…”
- “Check for…”
- “Test that…”

 Trace them back to the source

 Remember that different applications arrange in different ways
- Think of MF, batch, C/S, web, e-commerce, GUI, etc.
- Use “testing considerations” checklists that generally cover what
kinds of things should be considered when testing your specific
situation
 Make your Test Requirements document a “living document”

14

Generating TR’s
 Also...
 Maintain a level of balance between too much & too little
- Too High level: won’t be useful, vague, can’t generate test cases
from it.
- Too low level: Over-process, over documentation, no productivity
- General rule: 5-7 levels deep in an outline format
 Organize them!
- Outline/Hierarchy format recommended
- Look at how the BA breaks down the project into areas
- Look at how the PA breaks down the project into areas
- Organize by functional areas
- Organize by “types” of testing (Function vs. System vs. Non-Functional)

15

Generating TR’s
Organizing by Functional areas….

 Mosttesters perform function-

based, or requirements-based tests
- Tests on functionality that the system will
provide
- Usually scenario/case based
- includes normal and alternate (invalid)
cases

16

Organizing TR’s
Organizing by Functional areas….
 Most testers also perform User
Interface Style Tests
- These are generally separate from the
functionality that the software will
provide
- Usually encompass the architectural
standards & compliance (like Windows
Design Standards)
- Also includes tests of navigation, menus,
admin functions (like printing, saving)
17

Organizing TR’s
Remember this?…Drilling down

Business
Requirement

Test
Requirement

Test
Scenarios/
Cases
Test
Procedure/
Script

18

Fitting TR’s into the testing picture

 Decomposing: Drilling down within a Test
Requirement

Business
Function
Tasks within the
Business Function
Transactions to
Requirement perform a task

Data Entry Types

for transactions

Field Validation
Test
Requirement

Keep the Test

function-based Scenarios/
perspective Cases
in mind! Test
Procedure/
Script
19

Fitting TR’s into the testing picture

 Test Requirement Decomposition

The "what" that the software is intended to

Business Function do, like "Rent a Car to a customer"

Tasks within the The tasks involved: 1) query car rates,

Function 2) check customer policy coverages, ....

Transactions to The database transactions necessary

perform a task to perform the task.

The types of data entry the Data Entry Types

transaction can process: Add, for transactions
Change, Delete, Inquire

The edits on the data included within

Field Validation
the different types

20

Decomposing TR’s
 Test Requirement Decomposition

Business High level Functional Areas:

Function usually from
“Functional Spec” type
Tasks within the
docs, or BA work
Function

Transactions to
perform a task
Lower level
Data Entry Types
Functional Areas:
for transactions
usually from
“Technical Spec” type
docs regarding Field Validation
internal logic,
21
or PA work
Decomposing TR’s
Test Requirement
Decomposition
 You can start on the high level functional areas early
into the project & build in lower level areas as they
become available
 Any level can contain a test requirement which can also
be made up of (or broken down into) lower level test
requirements

22

Decomposing TR’s
Example 3: Rental Car Application
1. Validate that a Rental can occur.
1.1 Check Customer policy coverage
1.2 Query Car availability
Let’s look at
1.3 Query Car rates
the lower levels
1.4 Open a Rental ticket for this one

1.4.1 Validate that a customer record can be entered

1.4.2 Validate that credit card approval is obtained
1.4.3 Validate that status on the car record is changed
from “waiting” to “rented”
Then we’ll try it
2. Billing Function
on this one
3. Reservation Function
23

Decomposing TR’s
 Example 3: Rental Car Application
1. Validate that a Rental can occur.
1.4 Open a Rental ticket
1.4.1 Validate that a customer record can be entered
1.4.1.1 Validate that a new customer can be added to
the customer table
1.4.1.1.1 Validate that the first name is all alpha
1.4.1.1.2 Validate that the age is > 21.
1.4.1.1.3 Validate that the phone number is
numeric
1.4.1.1.4 Validate area code is an existing area
code number.
1.4.1.2 Validate changing an existing customer
24

Decomposing TR’s
 Example 3: Rental Car Application
1. Validate that a Rental can occur.
1.4 Open a Rental ticket
1.4.2 Validate that credit card approval is obtained

…fill in the lower level test requirements!

First, Identify any sub-areas (further tasks, or even

separate transactions within this)
Then, Identify the lowest level field validation test
requirements (think about what is typically
involved with credit card authorizations)
25

Decomposing TR’s
 What did you come up with?
1. Validate that a Rental can occur.
1.4 Open a Rental ticket
1.4.2 Validate that credit card approval is obtained
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
_________________________________________
26

Decomposing TR’s
 Possible Test Requirements...
1. Validate that a Rental can occur. Function

1.4 Open a Rental ticket Task Transaction

1.4.2 Validate that credit card approval is obtained

1.4.2.1 Validate the expiration date is a valid future date
1.4.2.2 Validate the expiration date is not within 1 month of
expiring.
1.4.2.3 Validate that the CC# is 12 digits
1.4.2.4 Validate that the $ amount is <= credit balance available
1.4.2.5 Validate that an authorization # is received.

27

Decomposing TR’s
Test Coverage Measures
 Test Requirements are the “what” of testing & are the basis for
establishing the completion of testing
 TR’s give us the point of measurement for test coverage
 Each TR should receive a Priority, Risk, and Weight
 Each TR should be tracked for Verification () and Validation (%)

28

Test Coverage Measures