Improve your test case coverage by using this test design technique

Decision Table Testing, State Transition & Error Guessing can be very powerful in increasing your test design coverage. Continuing from the previous blog about test design techniques: Equivalence Partitioning and Boundary Value Analysis, in this post, I will explain other design techniques that are commonly used in software testing:

1. Decision Table Testing
2. State Transition Testing
3. Error Guessing

Decision Table Testing

What is a Decision Table

The decision Table technique is one of the BlackBox test design techniques in software testing. This technique is used when there are different combinations of input for the test conditions which will have different outcomes for each combination of test inputs. Usually, this Decision table testing is used when there are complex business rules to be tested and using this technique will help to identify the correct test cases to be tested. Generally, it is applied when the specification requirements or business rules are in the form of tables or flow charts. 

Why is the Decision table commonly used in Software testing? Because the main and the most important objective of Decision table testing is to ensure 100% test coverage without missing any possible relation between the input combinations and the expected outcome from each input. Besides covering the possibilities from all specification requirements relation, the Software QA is also required to consider if any boundary values check to exist between each rule while creating the decision table. 

Below are the guidelines on how you could design the Decision Table:

Guidelines for Decision Table Testing

Given the requirements below as the example for designing the decision table:

Requirement: 

Transfer money is successful when the user enters the valid beneficiary account, and also the amount is sufficient with the correct OTP entered for the verification. 

The workflow is as follows:

These are the steps on how you could design the decision table based on the requirements above:

Step #1 – Analyze the requirement and create the first column

Based on the requirements above, to analyze the requirement, you could define the conditions and the corresponding actions. In the case above, there are 3 conditions and also 3 actions. We can create the first column with the conditions and actions accordingly:

Conditions

Is the account approved?

OTP matched?

Sufficient balance?

Actions

Block the transaction

Show message as “Insufficient Amount”

Transfer Money

Step #2 – Add Columns

Once the first column is created, now you could add more columns which indicate the combination of input and outcomes. The number of columns that are required to be added to the decision table depends on the number of conditions and the number of actions of each condition. If there are two conditions and each condition can be either true or false, then the tester needs to add 4 columns. Based on the requirements in step #1, we have 3 conditions, hence there will be 8 columns. 

Mathematically, the number of columns is 2^conditions. In this case, 2³ = 8 columns. 

Once the columns are defined, you could then start to add the True and False values on each condition for the actions, refer to the flow chart in the requirements section and you will place the check mark on each action against the combinations of each condition. You may put (-) when the input doesn’t have the outcome accordingly as this column will be removed in the next step.  Refer to the column below for the example:

Conditions	TC1	TC2	TC3	TC4	TC5	TC6	TC7	TC8
Account is Approved?	T	T	T	T	F	F	F	F
OTP Matched?	T	T	F	F	T	T	F	F
Sufficient amount balance?	T	F	T	F	T	F	T	F
Actions
Block the transaction			✓	✓	–	–	–	–
Show message as “Insufficient Amount”		✓			–	–	–	–
Transfer Money	✓				–	–	–	–

Step  3 – Reduce the table 

As mentioned in the step #2, for the columns which have invalid combinations or that are identical, you can delete them. Invalid combinations are those that cannot happen. For example, in the case above from TC5-TC8 when the Account is not approved, there are no other actions at the bottom that will happen. The TC 5 is considered an invalid test case, but we could keep this column as a negative test case. The columns TC6-8 are identical to TC5, so we could remove these. 

The column will be as follows:

Conditions	TC1	TC2	TC3	TC4	TC5
Account is Approved?	T	T	T	T	F
OTP Matched?	T	T	F	F	T
Sufficient amount balance?	T	F	T	F	T
Actions
Block the transaction			✓	✓	–
Show message as “Insufficient Amount”		✓			–
Transfer Money	✓				–

Step 4 – Write Test Cases

Once the table is designed, you can write the test cases based on the table from step #3. At least one test case per column gives full coverage of all business rules. 

Examples of the test cases that you could write are:

TC1	Verify that the user is able to transfer money when the account is approved, otp is matched and the amount balance is sufficient.
TC2	Verify that the system will display the message “Insufficient Amount” when the user is trying to transfer with an insufficient balance
TC3	Verify that the system will block the transfer process when the user is trying to transfer money with the OTP that does not match.
TC4	Verify that the system will block the transfer of money when the user is trying to transfer money with the OTP that does not match and the amount balance is insufficient.
TC5	Verify that the user is not able to transfer money when the Account is not Approved.

Advantages and Disadvantages of Decision Table Test Design Technique

Advantages of Decision Table Testing	Disadvantages of Decision Table Testing
The Decision table could help to make effective combinations and will be able to ensure better coverage for testing.	Decision tables only present a partial solution
Simple to understand and everyone can use this method to design the test scenarios and test cases.	The decision table does not depict the flow of logic of a solution
Any complex business flow can be easily converted into test scenarios and test cases.	Decision tables are quite far away from high-level languages.

State Transition

What is State Transition

State Transition is also one of the black box testing techniques. Different from the Decision table technique, in this state transition technique the outcomes are triggered by the changes to the input conditions or changes to the “state” of the system. The state transition technique is usually used when the system is defined as the number of states and the transition between the states is provided by the rules of the systems. 

There are two main ways to represent or design the state transition, which are using the State transition diagram and state transition table. I will explain more about the State Transition Diagram and State Transition Table with their differences and examples below:

State Transition Diagram and State Transition Table

State Transition Diagram shows how the state of the system changes on certain inputs. In this diagram, there are four main components:

1. States – State is a distinguishable situation of a system. A system can only be in one state at any point in time. A system can transition from one state to another.
2. Transition – A Transition is a change from one state to another. A transition may also be to the same state (a “transition-to-self”)
3. Events – An event in an occurrence inside or outside a system that can result in a transition. 
4. Actions – An action is behaviour executed at a particular point in the system. It can also be a string of actions. 

In the state transition diagram, the states are shown in boxed texts, and the transition is represented by arrows. It is useful in identifying valid transitions. Refer to the image below on how the state transitions diagram sample:

In the State Transition Table, all the states are listed on the left side and the events are described on the top. Each cell in the table represents the state of the system after an event has occurred. 

State\Events	Event 1	Event 2	Event 3
S1
S2
S3
S4

Guidelines for State Transition testing

Example:

Consider an online banking system where if the users enter invalid OTP 3 times the account will be blocked

In this system, if the user enters a valid OTP in any of the first three attempts the user will be able to transfer the money successfully. If the user enters the invalid OTP for the first or second try, the user will be asked to re-enter the OTP. But if the user enters an incorrect OTP on the third try, the account will be blocked.

The diagram below shows that how the money transferring process using OTP:

Step #1 Create the Transition table from the diagram transition

In the transition table, list out the State transition as a row, and the event as a column.

State	Valid OTP	Invalid OTP
S1 – Enter OTP	S5	S2
S2 – 1st Try	S5	S3
S3 – 2nd Try	S5	S4
S4 – 3rd Try	S5	S6
S5 – Money Transferred Successfully	–	–
S6 – Account Blocked	–	–

The value of each event is where the transition of each state against the event. From the table, when the user enters the valid OTP, the state is transitioned to S5 which is Money Transferred successfully. If the user enters an invalid OTP, then the next transition is to S2 which is 1st Try. If the user does the same up until the 3rd time, then the user will reach the state S6 which is the Account blocked state.

Step #2 Write Test Cases

Once the transition table is designed, you can write the test cases based on the transition table from step #1. At least one test case per column gives full coverage of all business rules. 

Examples of the test cases that you could write are:

TC1	Verify the money is transferred successfully when the user enters the valid OTP
TC2	Verify the money is transferred successfully when the user enters the valid OTP after the first try entering an invalid OTP
TC3	Verify the money is transferred successfully when the user enters the valid OTP after the 2nd try entering an invalid OTP
TC4	Verify the money is transferred successfully when the user enters the valid OTP after the 3rd try entering an invalid OTP
TC5	Verify the user is able to reenter the OTP again after entering the invalid OTP for the first try
TC6	Verify the user is able to reenter the OTP again after entering the invalid OTP for the 2nd try
TC7	Verify that the account is blocked when the user enters an invalid OTP for the 3rd time.

Advantages and Disadvantages of State Transition Test Design Technique

Advantages of State Transition Testing	Disadvantages of State Transition Testing
By using the state transition table, the tester is able to see the full coverage of test cases as the conditions are covered.	With this technique, the tester needs to define all possible states of a system. This will not be a problem when the requirement is small, but when it comes to a more complex system, this technique will not be efficient to use as there is an exponential progression in the number of states.
Using this technique gives a proper representation of the system’s behaviour.	When using this state transition testing, the tester can’t always rely on this technique. For example, if the system is not in sequential order or not in a finite system, this technique can’t be used.

Error Guessing

What is Error Guessing?

In software testing, Error Guessing is another black-box testing technique which is experience-based. Because of this, it requires skilled and experienced testers as they can use their experiences to guess the common problematic areas of the application.

This technique does not follow any specific rules. So the scope of the test cases depends on the kind of testing the tester has been involved in. This Error Guessing technique can be used at any level of testing. The following are the common mistakes that an experienced tester will check during the error guessing testing:

• Entering an invalid data type on the fields (e.g entering an integer in the field that only accepts a string data type)
• Pressing the submit button without entering the value on the mandatory fields
• Uploading the files when exceeding the maximum limits or different file types from what it’s accepted
• Entering invalid parameters

The following factors can be used to guess the errors:

• Lessons learned from the previous release
• The tester’s intuition and experiences
• Previous defects that have been found
• Production issues reported by the customer
• Application UI
• Variety of data used for testing

Guidelines for Error Guessing

Since the Error Guessing technique is an experience-based test, it is difficult to give a well-defined guideline for this technique. However, you could learn about how you could perform the error guessing technique and also improve your analytical thinking:

1. Gain knowledge of technical understanding – Do not only rely on what errors will happen on the application but have a better understanding of the technical side such as: how the code is written, the concepts of the array, indexes, boundaries, loop, etc are implemented in the code. Besides, you could also learn about the technical environment such as server, operating system and database. This will help you to gain more experience in the Error guessing technique.
2. Understand what kind of errors tend to be made – An experienced tester would know what types of errors tend to occur in the past. e.g On the payment billing system application where the tax calculation logic has often failed with the application with different tax rules. In such cases, the tester will try different kinds of combinations between changing the tax rules with the invalid and valid data and see if the logic is still working fine.

Example of Error Guessing Technique:

There is a requirement to the “register a new account” feature where it states that the password should consist of 8 characters minimum with the combinations of lower case, upper case, special characters and numbers, and this Password field is mandatory.

Based on the requirement above, these are the Error guessing techniques you can use:

• What will be the result if the Password field is left blank?
• What will be the result if only lowercase characters are entered in the Password field?
• What will be the result if the combination of values entered is less than 8 characters?
• What will be the result if the combination of values entered is more than 8 characters?
• What will be the result if the value is entered only numeric?

Besides the sample of the error guessing mentioned above, you could still produce other scenarios based on your experience with how you test an application.

Advantages and Disadvantages of the Error Guessing Technique

Advantages of the Error Guessing Technique	Disadvantages of the Error Guessing Technique
By using this technique, it is very helpful to guess problematic areas of the application.	This technique is only able to be performed by experienced testers. The focal shortcoming of this technique is that a person is dependent.
By using this technique, you could help to uncover the defects that couldn’t be found through formal testing.

Key Takeaways

1. The Decision Table technique is used when there are different combinations of the input for the test conditions which will have different outcomes for each combination of test inputs.
2. There are two main ways to represent or design the test cases using the State Transition test design technique, State Transition Diagram and State Transition Table
3. The difference between the State Transition technique from the Decision table technique, in this state transition technique the outcomes are triggered by the changes to the input conditions or changes to the “state” of the system
4. The Error Guessing technique does not follow any specific rules. So the scope of the test cases depends on what kind of testing the tester was involved in the past.

Reference

1. State Transition Guidelines
2. Error guessing technique in Software testing
3. Guidelines for Decision Table Techniques