6 Test Case Design Techniques in Software Testing helping you to deliver Better Quality

How many times have you been given requirements and you’ve just wanted to start writing your tests?

Me too.

Before you embark on your next software testing project, I’d like to familiarise you with a number of effective test case design techniques that you might want to consider.

What do you mean by Test Case Design Techniques?

Test case design techniques are essentially a number of proven methods that allow you to create test cases as efficiently as possible whilst ensuring sufficient test coverage.

Having knowledge of the techniques mentioned below will allow you to take a step back and actually think about how to approach the test design phase.

For example, if you come from a manual testing background and are used to writing a test script format where you write step by step, this may not always be the best approach to test your system.

Read on.

Types of Test Design Techniques

I believe in providing good examples to make learning easier and so I’m not going to start writing long, boring definitions that might make you fall asleep.

Black Box / Functional Testing

Boundary Value Analysis (BVA)

Boundary value analysis is a test case design technique used to identify errors in input values that are at the edge of valid input values for a system.

One situation where boundary value analysis is used is when testing a system that accepts decimal input. In this case, the tester would try inputting the minimum and maximum values as well as the values just inside those boundaries.

Example.

Let’s say you order a product online and qualify for free delivery if you spend £50 or more.

The boundary values in this case would be;

£49.99 – No Free Delivery

£50.00 – Qualifies for Free delivery

£50.01 – Qualifies for free delivery

What we;re doing is essentially testing the ‘edge’ of the value to ensure it’s calculated correctly.  You might want to ensure that it’s been rounded correctly.

Equivalence Partitioning

Equivalence partitioning is a technique used in software testing to divide input data into classes that are expected to produce the same results.

This is done by selecting test data from each class that will be representative of the other data in the class.

For example, if you were testing an application that accepts a user’s age, you would select valid input values such as 18, 25 and 30 to represent the other valid input values within the “age” class.

Another example of equivalence partitioning would be testing a login feature on a website.

The inputs for this feature would be a username and password.

You would create classes for valid and invalid inputs, and then select test data from each class that is representative of the other data in the class.

For example, a valid input for the username class might be “testuser” and an invalid input might be “test user” (note the space between “test” and “user”).

Another great example I like to use is that of “Tax Brackets” in payroll processing. 

Below is a very oversimplified version taken from the UK Government’s page..

There are clear partitions that define how much tax a person needs to pay depending on their income.

Partition Number	Name of Bracket	Minimum Value (£ per year)	Maximum Value (£ per year)	Tax Rate %
1	Personal Allowance	0	12,570	0
2	Basic Tax Rate	12,571	37,700	20
3	Higher Tax Rate	37,701	150,000	40
4	Additional Tax Rate	150,001		45

So for example if my annual gross salary is between £0 and £12,571 then I fall into partition 1 where I would only pay 0% in taxation.

In order to prove your tests, you should prove each partition.

Decision Tables

Decision tables are a test case design technique that can be used to help identify errors in input values.

They are especially helpful when testing systems that have a number of input variables. 

In order to create a decision table, you first need to list all of the input variables and their corresponding test values. 

Then, for each row in the table, you need to write a test condition that will be evaluated when the input variable is set to that value. 

The test condition should return either true or false depending on whether the system under test passes or fails the given test. 

Finally, you need to write the expected result for each row in the table. 

An example decision table for testing an age calculator might look like this:

Input Variables: 

Age (in years) – valid input values: 18, 25, 30 

Test Values: 

18, 25, 30 

Test Conditions: 

(age >= 18) and (age <= 25), (age >= 30) and (age <= 35) 

Expected Results: 

Success message for ages 18-25 and 30-35, Failure message for age 26-29

Another example that comes to mind is role based access control (RBAC) testing.

This as it’s time consuming, laborious and boring item to test which unfortunately is very necessary.

Rather than writing a step by step test case, wouldn’t it be easier if you just had a table where you could check the permissions of each profile?

Much simpler right?

Profile / Permissions	Admin(Profile 1)	Application Super User(Profile 2)	Application User(Profile 3)
User Admin
Create New User	Yes	No	No
Delete User	Yes	No	No
Amend User Details	Yes	Yes	No
Analytics and Reporting
Create New Report	No	Yes	No
Delete Report	No	Yes	No
Amend Report	No	Yes	No
Run report	No	Yes	Yes

State Transition (tables and diagrams)

State transition testing is a type of black-box testing that is used to determine if a system can transition from one state to another. 

To perform state transition testing, you first need to identify the different states that the system can be in, and then you need to define the conditions that must be met for the system to transition from one state to another. 

An example of state transition testing would be testing an online shopping cart. The different 

states could be “empty cart”, “cart with one item”, “cart with multiple items” and “checkout”. 

The conditions that would need to be met for the system to transition from one state to another could be something like “the total number of items in the cart is greater than 5”, or “the total price of the items in the cart is less than £50”. 

State transition testing can be done using state transition tables or state transition diagrams. 

State transition tables list all of the possible states and the conditions that need to be met for the system to transition from one state to another. 

State transition diagrams visually represent the different states and the transitions between them.

An ATM is a good example that comes to mind.

Experience Based Techniques

You can also create test cases using your own and other’s experiences.  Let me break these down a bit further below.

Exploratory Testing

Exploratory testing is a type of black-box testing that is used to find defects in the system. It’s done by randomly exploring the system and trying different things to see what happens. 

An example of exploratory testing would be testing a login feature on a website. You would try different username and password combinations to see if you can log in. 

If you can’t log in, you should try different username and password combinations until you find one that works. 

Exploratory testing can be done by any member of the team, not just the test engineer. 

This makes it a very flexible and fast way to test the system.

Using this method is good when you have a “bug bash” or where you need lots of people to test functionality in a short space of time.

Generally, I wouldn’t recommend using this test design technique as a primary way to test a system unless you know the system and requirements VERY well.

Or, unless you have a strategic plan on how you’ll test.

Error Guessing

Error guessing is a type of black-box testing that is used to find defects in the system. It is done by guessing the input values that will cause the system to fail. 

An example of error guessing in software testing would be trying to enter text into a text input field that is not meant to accept text. You would try different text combinations until you find one that causes an error.

Another example of error guessing would be trying to enter a invalid date into a date input field.

When used properly, this can be a very powerful method to try and “throw” your application under test.

Ideally you would need some experience of the system under test (or similar systems) in order to guess where the error may be.

How do I know which Test Case Design Techniques to Use?

My advice is to look at the type of requirements your project has to help determine the kind of test cases you should be writing.

So for example, calculations may benefit from equivalence partitioning and boundary value analysis testing. 

Whereas if you’re making decisions, you may want to use decision table testing.

A role based test may be suited towards decision tables.

Your project will determine the kind of tests you write.

Remember, you don’t have to stick to one test design technique for your project.  Use the most efficient method necessary in order to prove your requirement.

The technique you use can be adopted across the board regardless of whether you conduct unit testing, system integration testing or User Acceptance Testing. 

Creating Your Regression Testing Suite

I always see test case writing as an investment.  

As you start to write more and more tests, over time you’ll accumulate a wide range of coverage which you can add to your regression testing suite.

Conclusion 

So there you have it.

Hopefully that’s giving you some food for thought about which Test case design techniques you can adopt for your next project.

Certain test design techniques are better suited to certain types of requirements.

As mentioned above, you don’t have to use the same test case template for all.  

Be smart and practical to ensure you get the most of your test design techniques.

I’m intrigued to know what approaches you use and what methods you use.