Test case design

Table of contents
1. Terminology
2. Best practices
3. Test case design techniques
a. Equivalence partitioning
b. Boundary value analysis
c. Decision table testing
d. State transition testing
e. Use case testing
4. How to ask questions

1. Terminology
Test Case
describes an input, action or event, and an expected response, to determine if a
feature of a software application is working correctly
Or simply put: a question you ask the program
has a single action --> it checks one action only

Use Case
is a description of a particular use of the system by the user
describes the interactions the end user has with the software system in order to
achieve a specific task

Test Case Design Technique = a method used to create and group test cases

Test Case Suite = a collection of one or more test cases

User Story is a small (actually, the smallest) piece of work that represents some
value to an end user and can be delivered during a sprint.

An Epic is a high-level body of work that bands together with a group of related
Stories.

An acceptance criteria is a set of conditions that are used to confirm when a

Story is completed.

2. Best practices

1
 Specify exactly what the tester has to do to create the desired input conditions
and exactly how the program should respond (the output). Be explicit in this
documentation so that multiple testers (other than yourself) would be able to run
the exact same test case using the directions in the test case.
Write the simplest test cases that could possibly reveal a mode of failure.
Write each test case so that it can reveal one type of fault.

Have a PURPOSE
Is easy to understand by others

Test happy flows first, alternative flows afterwards

Positive tests: application does what is supposed to do, in all possible manners
Negative tests like: numeric values, date format, field size,…
Relational tests: duplicate records, delete records with dependencies

Do ONE, and only one test at a time

Use preconditions if they are specific (e.g. test create duplicate contact;
precondition is that the contact already exist)

Add test data if needed (e.g. credit card)

Use naming conventions (e.g. Login – invalid username)

Have a logical grouping in sections

3. Test case design techniques

3.1. Equivalence partitioning
Equivalence partitioning is based on a very simple idea: in many cases the inputs to a
program can be ‘chunked’ into groups of similar inputs. For example, a program that
accepts integer values can accept as valid any input that is an integer (e.g. a whole
number) and should reject anything else (such as a real number or a character).
In this technique, only one condition is going to be tested from each partition, because
we assume that all the conditions in one partition behave in the same manner.
This method is typically used to reduce the total number of test cases to a finite set of
testable test cases, still covering maximum requirements.
In short, it is the process of taking all possible test cases and placing them into classes.
One test value is picked from each class while testing.
EXAMPLE: If you are testing for an input box accepting numbers from 1 to 32 then there
is no use in writing 32 test cases for all 32 valid input numbers, plus other test cases for
invalid data.

2
Using equivalence partitioning method above test cases can be divided into three sets
of input data called as classes; each test case is a representative of respective class.
So, we divide our test cases into three equivalence classes of some valid and invalid
inputs:
1: One input data class with all valid inputs. Pick a single value from range 1 to 32 as a
valid test case; any other value between 1 and 32 is going to be the same. So, one test
case for valid input data should be sufficient.
2: Input data class with any value below lower limit (below 1), as an invalid input data
test case.
3: Input data with any value greater than upper limit (greater than 32) to represent
another invalid input class.
Test cases with other values from any of these 3 classes will give you the same result.
NOTE: Equivalence partitioning uses fewest test cases to cover maximum
requirements.

3.2. Boundary Value Analysis

Boundary Value Analysis is a software testing technique in which test cases are
designed to include representatives of boundary values in and out of a given range. A
boundary value is an input or output value on the border of an equivalence partition,
includes minimum and maximum values at inside and outside boundaries. Normally
Boundary value analysis is part of stress and negative testing.
It’s widely recognized that input values at the extreme ends of input domain cause more
errors in system. More application errors occur at the boundaries of input domain.
‘Boundary value analysis’ testing technique is used to identify errors at boundaries
rather than finding those exist in center of input domain. The rule is that we use the
boundary value itself and one value (as close as you can get) either side of the
boundary. What does ‘as close as we can get’ mean? It means take the next value in
sequence using the precision that has been applied to the partition. For most practical
purposes the boundary value analysis technique needs to identify just two values at
each boundary.
EXAMPLE: Test cases for input box accepting numbers between 1 and 32 using
Boundary value analysis:
1:Test cases with test data exactly as the input boundaries of input domain e.g. values 1
and 32 in our case.
2: Test data with values just below the extreme edges of input domains e.g. values 0
and 31.
3: Test data with values just above the extreme edges of input domain e.g. values 2 and
33.

3
NOTE: There is no hard-and-fast rule to test only one value from each equivalence
class you created for input domains. You can select multiple valid and invalid values
from each equivalence class according to your needs and previous judgments.

3.3. Decision table testing

Decision table is a specific way to model complex rule sets and their corresponding
actions. Each decision corresponds to a variable, relation or predicate whose possible
values are listed among the condition alternatives. Each action is a procedure or
operation to perform, and the entries specify whether (or in what order) the action is to
be performed for the set of condition alternatives the entry corresponds to. Generally,
decision tables use simple true/false values to represent the alternatives to a condition.
A decision table lists all the input conditions that can occur and all the actions that can
arise from them. These are structured into a table as rows, with the conditions at the top
of the table and the possible actions at the bottom. Business rules, which involve
combinations of conditions to produce some combination of actions, are arranged
across the top. Each column therefore represents a single business rule (or just ‘rule’)
and shows how input conditions combine to produce actions. Thus each column
represents a possible test case, since it identifies both inputs and expected outputs.
Testing combinations can be a challenge, as the number of combinations can often be
huge. Testing all combinations may be impractical if not impossible. It is always better to
prioritize and test the most important combinations.
Decision Table Testing is a good way to deal with a combination of inputs, which
produce different results.
EXAMPLE: Let's have in mind the behavior of Flight button for different combinations of
Fly from & Fly to dropdowns.

4
1: When destination for both Fly from & Fly to are not set, the Search Flights button is
disabled. In the decision table, we register values false (F) for Fly from & Fly to and the
outcome would be false (F), which means Flights button is disabled.
2: When Fly from destination is set but Fly to is not set, Flight button is disabled.
Correspondingly, you register true (T) for Fly from destination in the decision table, and
the rest of the entries are false (F).
3: When Fly from destination is not set but Fly to destination is set, Flight button is
disabled and you make entries in the decision table.
4: When Fly to and Fly from destinations are set, Flight button is enabled and you make
the corresponding entry in the decision table (all true).
In a decision table, conditions are usually expressed as true (T) or false (F):

Conditions Rule 1 Rule 2 Rule 3 Rule 4

Fly from F T F T

Fly to F F T T

Actions flights F F F T

5
button

NOTE: This technique, a table which shows different combination inputs with their
associated outputs, it is also known as ‘cause-effect’ table.

3.4. State transition testing

State Transition testing is a technique in which outputs are triggered by changes to the
input conditions or changes to 'state' of the system. It can be used to design test cases
for a system that acquires finite number of states and can transit from one state to
another upon specific events.
A state transition model has four basic parts: start state, input (or event), output (or
action), finish state.
It is important to know that in any given state, one event can cause only one action, but
that the same event from a different state may cause a different action and a different
end state.
If we have a state transition diagram representation of a system we can analyze the
behavior in terms of what happens when a transition occurs. Transitions are caused by
events and they may generate outputs and/or changes of state. An event is anything
that acts as a trigger for a change; it could be an input to the system, or it could be
something inside the system that changes for some reason.
In some cases an event generates an output, in others the event changes the system’s
internal state without generating an output, and in still others an event may cause an
output and a change of state. What happens for each change is always deducible from
the state transition diagram:
Example:

6
3.5. Use case testing
Use case testing is a technique that helps us identify test cases that exercise the whole
system on a transaction by transaction basis from start to finish.
Use cases are defined in terms of the end user and not the system, use case describe
what the user does and what the user sees rather than what inputs the software system
expects and what the system outputs.
Each use case must specify any preconditions that need to be met for the use case to
work. Use cases must also specify post conditions that are observable results and a
description of the final state of the system after the use case has been executed
successfully.
Use Cases capture the interactions between 'actors' and the 'system'. 'Actors' represent
users and their interactions that each user takes part into. An actor represents a
particular type of user and the use cases capture the interactions that each user takes
part in to produce some output that is of value
Example
1: Consider the first step of an end to end scenario for a login functionality for our Flight
Reservation application where the actor enters agent name and password to login into
the Flight Reservation application.
2: In the next step, the system will validate the password
3: Next, if the password is correct, the access will be granted
4: There can be an extension of this use case. If password is not valid, the system will
display a message and ask for re-try four times; or if password is not valid four times,
the system will close the application

In practice, writing a test case to represent each use case is often a good starting point
for testing, and use case testing can be combined with other specification based testing.

NOTE: Use case testing has the major benefit that it relates to real user processes, so it
offers an opportunity to exercise a complete process flow. The principles applied
elsewhere can be applied here: first test the highest priority (highest value) use cases
by taking typical examples; then exercise some attempts at incorrect process flows; and
then exercise the boundaries.

4. How to ask questions as a software tester

Summary: Asking questions plays an important role in software testing. It isn’t easy—
actually, it may be one of the most difficult skills to master—but it’s worth the effort
because the more you ask, the more you learn.

1. Don’t be afraid to ask questions

7
We are worried we’ll look stupid. When we ask questions, we are telling people we don’t
know something. Asking a question can make you vulnerable.
We believe we “should” know things. This is especially true of people who have more
experience. We tend to assume things and say, “I’ve been a tester for twelve years. I
should be able to figure this out by myself.”
2. Ask open-ended questions
Questions you can answer “yes” or “no” are closed-ended. They don’t generate
discussion and they rarely yield any insight.
3. Add More Context
Beyond the root cause, the context explains the classic journalism questions—who,
what, when, where, why, and how.
So, instead of just asking about a good test management tool, add context by saying
how long you have had the problem you’re trying to fix, what you’ve found in the
background research you have already done, what you have tried so far and how it
worked out, and what you will do with the answers.
A better-crafted inquiry would be:
My team of three is currently using Excel spreadsheets to manage test cases, and it
works fine. However, my team will be growing to ten or more people and may be
distributed, so I’m looking for a new test management tool.
I want a free, web-based tool that works with both Mac and Windows and can link test
requirements and test cases.
I’ve tried Bugzilla, but I don’t have a server to install software on, and I need something
easier and more user-friendly.
Can you give me some other suggestions?
This inquiry is much better because it gives the context around the questions. With this
inquiry, you’ll be much more likely to get the kind of answer you want.
4. Ask Five Whys
Asking “Why?” five times is a popular root-cause analysis activity. It’s an iterative
question-asking technique used to explore the cause-and-effect relationships underlying
a problem.
Here’s an example:
The vehicle will not start. (The problem)
Why? The battery is dead.
Why? The alternator is not functioning.
Why? The alternator belt has broken.
Why? The alternator belt was well beyond its useful service life.
Why? The vehicle was not maintained according to the recommended service schedule.
Because you continued asking why, you finally got an answer that gives the root cause.
5. Get behind the assumptions

8
Every business decision is based on assumptions. If you don’t understand these
assumptions, you may make a bad decision. It’s often helpful to ask yourself first—and
then your colleagues—, “What are we assuming in this scenario?”
Then you need to keep peeling the layers off the onion until you get comfortable with
the assumptions. This is where people often make mistakes. Their logic may be
impeccable, but if it’s built on faulty assumptions, it will lead to a faulty conclusion.