Software Test Design Techniques

TEST DESIGN TECHNIQUES
Test design techniques helps to design better cases. It Reduce the number of test cases to be executed.

1. Equivalence Class Partitioning
2. Boundary Value Analysis (BVA)
3. Decision Table based testing.
4. State Transition
5. Error Guessing

EQUIVALALENCE CLASS PARTITIONING (ECP):

Partition data into various  classes and we can select data according to class then test. It reduce the number of test-cases and saves time for testing.

Equivalence Class Partitioning Example 1:

Requirement: The system should accept ages between 18 and 60.

Equivalence Classes:

Equivalence Class	Age Range
1	18 to 25
2	26 to 35
3	36 to 45
4	46 to 60
5	Less than 18
6	Greater than 60

This table represents the different equivalence classes based on valid and invalid age ranges.

Test Cases:

1. Test with an age of 22 (Valid - Equivalence Class 1).
2. Test with an age of 30 (Valid - Equivalence Class 2).
3. Test with an age of 40 (Valid - Equivalence Class 3).
4. Test with an age of 55 (Valid - Equivalence Class 4).
5. Test with an age of 16 (Invalid - Equivalence Class 5).
6. Test with an age of 65 (Invalid - Equivalence Class 6).

Equivalence Class Partitioning Example 2:

Requirement: An online shopping website that allows users to enter the quantity of items they want to purchase. The valid quantity is between 1 and 10.

Equivalence Classes:

Equivalence Class	Quantity Range
1	1 to 10
2	Less than 1
3	Greater than 10

This table represents the different equivalence classes based on valid and invalid quantity ranges. 

Test Cases:

1. Test with a quantity of 5 (Valid - Equivalence Class 1).
2. Test with a quantity of 1 (Valid - Equivalence Class 1).
3. Test with a quantity of 10 (Valid - Equivalence Class 1).
4. Test with a quantity of 0 (Invalid - Equivalence Class 2).
5. Test with a quantity of 15 (Invalid - Equivalence Class 3).

Equivalence Class Partitioning Example 3:

Requirement: A user name box allowed only alpha numeric data.

Equivalence Classes:

Equivalence Class	Description
1	Valid Alphanumeric Username: Alphanumeric values that meet general username requirements.
2	Invalid Username: Any username that contains special characters.
3	Invalid Username: A username that consists of only blank spaces or is completely blank.

This table represents the different equivalence classes based on valid and invalid criteria for usernames. 

Examples:

1. Valid Alphanumeric Username:
• Username: "JohnDoe123" (Valid - Equivalence Class 1)
2. Invalid Username with Special Characters:
• Username: "User@123" (Invalid - Equivalence Class 2)
3. Invalid Username with Blank or Whitespace:
• Username: " " (Invalid - Equivalence Class 3)
4. Valid Alphanumeric Username with Mixed Case:
• Username: "TechieUser456" (Valid - Equivalence Class 1)
5. Invalid Username with Leading Whitespace:
• Username: " Geek123" (Invalid - Equivalence Class 3)
6. Invalid Username with Trailing Whitespace:
• Username: "SmartCoder " (Invalid - Equivalence Class 3)
7. Invalid Username with a Mix of Alphanumeric and Special Characters:
• Username: "Alpha@Numeric" (Invalid - Equivalence Class 2)

BOUNDARY VALUE ANALYSIS (BVA):

Boundary Value Analysis (BVA) is a testing technique where we focus on testing the boundaries or edges of valid and invalid input values. The idea is that many errors in software occur at the extreme values or boundaries. Let's look at a simple example to understand BVA:

Scenario: An input box that accepts a number as input, and the valid range is 1 to 100.

Test with the Minimum Valid Input:

If the valid range is 1 to 100, test the program with the smallest valid input, which is 1. This helps ensure that the program handles the lowest allowed value correctly.

Test with the Maximum Valid Input:

Similarly, test with the largest valid input, which is 100. This ensures that the program works well with the highest allowed value.

Test with Values Just Below the Valid Range:

Check how the program behaves with values right below the valid range, like 0. This helps catch any issues with values slightly outside the allowed range.

Test with Values Just Above the Valid Range:

Test with values slightly above the valid range, such as 101. This helps identify if the program can handle inputs that are a bit higher than the maximum allowed.

Test with Values Inside the Valid Range:

Lastly, test with a regular value inside the valid range, like 50. This ensures that the program works properly with typical inputs.

DECISION TABLE

• Decision Table is also called as Cause-Effect Table.
• This technique will be used if we have more conditions and corresponding actions.
• In Decision table technique, we deal with combinations of inputs. 
• To identify the test cases with decision table, we consider conditions and actions. 

Decision Table (Example 1):

Let's consider a simple decision table for determining whether a person is eligible for a discount based on their age and membership status:

Condition 1 (Age)	Condition 2 (Membership)	Action
Below 18	Any	No
18 to 25	Yes	Yes
18 to 25	No	No
26 and above	Any	Yes

In this example:

Condition 1 (Age) has three values: Below 18, 18 to 25, and 26 and above.

Condition 2 (Membership) has two values: Yes and No.

Action has two values: Yes (eligible for a discount) and No (not eligible).

Explanation:

If the person is below 18, irrespective of their membership status, they are not eligible for a discount.

If the person is between 18 and 25:

If they have a membership, they are eligible for a discount.

If they don't have a membership, they are not eligible for a discount.

If the person is 26 or above, irrespective of their membership status, they are eligible for a discount.

Testing:

You can use this decision table to create test cases that cover all possible combinations of conditions. For instance, you would create test cases to cover scenarios like:

• A person below 18 with a membership.
• A person between 18 and 25 without a membership.
• A person 26 or above with or without a membership.

Decision Table (Example 2):

Let's create a decision table for the online money transfer scenario based on the given conditions and actions:

Condition: Account Approved	Condition: OTP Matched	Condition: Sufficient Money	Action: Transfer Money	Action: Insufficient Amount	Action: Block Transaction
Yes	Yes	Yes	Yes	No	No
Yes	Yes	No	No	Yes	No
Yes	No	-	No	No	Yes
No	-	-	No	No	Yes

Explanation:

• If the account is approved, OTP is matched, and there is sufficient money, the action is to transfer money.
• If the account is approved, OTP is matched, but there is insufficient money, the action is to show a message about insufficient amount.
• If the account is approved, but OTP is not matched, the action is to block the transaction.
• If the account is not approved, irrespective of OTP, the action is to block the transaction.

Example Test Scenarios:

1) Test Scenario: Successful Money Transfer

Account Approved: Yes

OTP Matched: Yes

Sufficient Money: Yes

Expected Result: Money should be transferred.

2) Test Scenario: Insufficient Amount

Account Approved: Yes

OTP Matched: Yes

Sufficient Money: No

Expected Result: Show a message about insufficient amount.

3) Test Scenario: Blocked Transaction (OTP Mismatch)

Account Approved: Yes

OTP Matched: No

Expected Result: Transaction should be blocked.

4) Test Scenario: Blocked Transaction (Account Not Approved)

Account Approved: No

OTP Matched: Doesn't matter

Expected Result: Transaction should be blocked.

STATE TRANSITION 

• In State Transition technique changes in input conditions change the state of the Application. 
• This testing technique allows the tester to test the behavior of an AUT. 
• The tester can perform this action by entering various input conditions in a sequence. 
• In State transition technique, the testing team provides positive as well as negative input test values for evaluating the system behavior.

State Transition Diagram and State Transition Table

There are two main ways to represent or design state transition, State transition diagram, and state transition table.

How to Make a State Transition (Examples of a State Transition)

Example :

Let’s consider an ATM system function where if the user enters the invalid password three times the account will be locked.

In this system, if the user enters a valid password in any of the first three attempts the user will be logged in successfully. If the user enters the invalid password in the first or second try, the user will be asked to re-enter the password. And finally, if the user enters incorrect password 3rd time, the account will be blocked.

State transition diagram

In the diagram whenever the user enters the correct PIN he is moved to Access granted state, and if he enters the wrong password he is moved to next try and if he does the same for the 3rd time the account blocked state is reached.

	Correct PIN	Incorrect PIN
S1) Start	S5	S2
S2) 1st attempt	S5	S3
S3) 2nd attempt	S5	S4
S4) 3rd attempt	S5	S6
S5) Access Granted	–	–
S6) Account blocked	–	–

In the table when the user enters the correct PIN, state is transitioned to S5 which is Access granted. And if the user enters a wrong password he is moved to next state. If he does the same 3rd time, he will reach the account blocked state.

ERROR GUESSING

Error guessing is a software testing technique where testers use their experience and intuition to identify potential areas of a system where errors or defects might occur. This technique relies on the tester's knowledge of the system

Imagine you are testing a calculator application. Here are a few examples of how error guessing might be applied:

Division by Zero:

Guess: Test what happens if the user tries to divide a number by zero.

Reasoning: Division by zero is a common error, and the program should ideally handle this situation gracefully.

Large Number Input:

Guess: Test how the calculator handles very large numbers.

Reasoning: Some calculators might struggle with extremely large numbers due to limitations in representation or processing capabilities.

Invalid Input Characters:

Guess: Test if the calculator can handle non-numeric input characters.

Reasoning: Users might accidentally input letters or symbols, and the calculator should be able to handle such situations without crashing.

Decimal Precision:

Guess: Test the precision of decimal calculations.

Reasoning: Ensure that the calculator accurately handles decimal points and doesn't introduce rounding errors.

Memory Overflow:

Guess: Test what happens when the calculator's memory overflows.

Reasoning: If the calculator has a memory feature, it should be tested to ensure it behaves correctly when the memory limit is reached.

Combination of Operations:

Guess: Test complex combinations of different operations (addition, subtraction, multiplication, division).

Reasoning: Check if the calculator gives correct results and doesn't get confused with sequences of various operations.

User Interface Resilience:

Guess: Randomly click buttons rapidly to simulate quick user actions.

Reasoning: Check if the calculator's user interface remains responsive and functional under rapid user interactions.

Switching Modes:

Guess: Test switching between different calculator modes (standard, scientific, programming).

Reasoning: Ensure that the calculator transitions smoothly between modes without causing unexpected errors.