SOFTWARE

QUALITY
ENGINEERING(
SQE)
How to write Testable Requirements?
1
 WHAT IS A
2
TESTABLE
REQUIREMENT?
 A testable requirement describes a single function or behavior of an
application in a way that makes it possible to develop tests to
determine whether the requirement has been met.
 To be testable, a requirement must be clear, measurable, and
complete, without any ambiguity.

3
 HOW TO WRITE A
4
TESTABLE
REQUIREMENT?
• For example, assume that you are planning to test a web shopping
application.
• You are presented with the following requirement: “Easy-to-use search for
available inventory.”
• Testing this requirement as written requires assumptions about what is
meant by ambiguous terms such as “easy-to-use” and “available
inventory.”
• To make requirements more testable, clarify ambiguous wording such as
“fast,” “intuitive” or “user-friendly.”
• Requirements shouldn’t contain implementation details such as “the
search box will be located in the top right corner of the screen,” but
otherwise should be measurable and complete. 

5
 HOW TO WRITE A
6
TESTABLE
REQUIREMENT?
 Consider the following example requirement for a web shopping platform:
 “FR_1: When at least one matching item is found, the system shall display
up to 20 matching inventory items, in a grid or list and using the sort
order according to the user preference settings.”
 However, this requirement describes more than one function. It would be
better practice to separate it into three separate testable requirements, as
shown below:
 FR_1.1: When at least one matching item is found, the system shall display up to 20
matching inventory items.
 FR_1.2: The system shall display search results in a grid or list according to the
user preference settings.
 FR_1.3: The system shall display search results in the sort order according to the
user preference settings.

7
 DONTS OF A
8
TESTABLE
REQUIREMENT
 Testable requirements should not include the following:
 Text that is irrelevant. Remove anything that doesn’t add value to your
understanding of the requirement.
 A description of the problem rather than the function that solves it.
 Implementation details.
 Ambiguity. Specifications should be specific. Avoid subjective terms
that can’t be measured, such as “usually.” Replace these with objective,
measurable terms such as “80%.”

9
 SAMPLE
10
TESTABLE
REQUIREMENTS
 SR_1: The system shall be able to verify the login credentials of the user
within three seconds.
 UR_2: Registered users shall be able to post maximum 5 post per day.
 SR_2: The system shall respond to all user commands and data entries
within five seconds.
 PROD_1: The application shall support windows and LINUX operating
systems.
 UR_3: The user shall be able to make a call using the internet connection
within 0.5 seconds.
 UR_4: The captain shall be able to contact the rider via phone call/ SMS.
 SR_3: The system shall display the details of the driver to the user after
0.5 seconds of ride booking.
11