Testing application or front end from the user point if view without looking the code is called Black box or Specification Testing. Black Box testing techniques are:
a) Equivalence Partitioning (EP)
b) Boundary Value Analysis (BVA)
c) Decision Table Testing
d) State Transition Testing
e) Use Case Testing Etc…
Equivalence Partitioning Testing:
Equivalence Partitioning is also known as Equivalence Class Partitioning. In equivalence partitioning, inputs to the software or system are divided into three groups (Invalid, Valid, Invalid) that are expected to exhibit similar behavior, so they are likely to be proposed in the same way. Hence selecting one input from each group to design the test cases.
Each and every condition of particular partition (group) works as same as other. If a condition in a partition is valid, other conditions are valid too. If a condition in a partition is invalid, other conditions are invalid too.
It helps to reduce the total number of test cases from infinite to finite. The selected test cases from these groups ensure coverage of all possible scenarios.
Example: Assume, we have to test a field which accepts Age 18 – 56
We have one valid and two invalid conditions here as below:
Valid Input: 18 – 56
Invalid Input: less than or equal to 17 (<=17), greater than or equal to 57 (>=57)
Test Scenario # Test Description Expected Result
| Invalid Test<=17 | Pick any one input test data less than or equal to 17 | should rejected |
| Valid Test: 18 – 56 | Pick any one input test data from 18 – 56 | should accepted. |
| Invalid Test >=57 | Pick any one input test data greater than or equal to 57 | should rejected |
Valid Test: 18 – 56 = Pick any one input test data from 18 – 56, should accepted.
Invalid Test 1: <=17 = Pick any one input test data less than or equal to 17, should rejected.
Invalid Test 2: >=57 = Pick any one input test data greater than or equal to 57, should rejected.
Boundary value Testing:
It is a process of testing between extreme ends or boundaries input values.The basic idea in boundary value testing is to select input variable at there:
- Minimum boundary value
- Below the minimum
- Just above the minimum
- A nominal value (like middle one)
- Just below the max boundary
- Maximum boundary value
- Just above the max
Example: Assume, we have to test a field which accepts Age 18 – 56
Minimum boundary value is 18
Maximum boundary value is 56
Valid Inputs: 18,19,55,56
Invalid Inputs: 17 and 57
Test Scenario # Test Description Expected Result
| Test case 1 | Enter the value 17 (18-1) | System should reject |
| Test case 2 | Enter the value 18 | System should accept |
| Test case 3 | Enter the value 19 (18+1) | System should accept |
| Test case 4 | Enter a nominal value 25 | System should accept |
| Test case 5 | Enter the value 55 (56-1) | System should accept |
| Test case 6 | Enter the value 56 | System should accept |
| Test case 7 | Enter the value 57 (56+1) | System should reject |
Decision Table Testing:
Decision Table is a Cause-Effect Table. This test technique is appropriate for functionalities which has logical relationships between inputs (if-else logic). In Decision table technique, we deal with combinations of inputs. To identify the test cases with decision table, we consider conditions and actions. We take conditions as inputs and actions as outputs.
Example: Take an example of transferring money online to an account which is already added and approved.
Here the conditions to transfer money are ACCOUNT ALREADY APPROVED, OTP (One Time Password) MATCHED, SUFFICIENT MONEY IN THE ACCOUNT.
And the actions performed are TRANSFER MONEY, SHOW A MESSAGE AS INSUFFICIENT AMOUNT, BLOCK THE TRANSACTION IN CASE OF SUSPICIOUS TRANSACTION.
Here we decide under what condition the action be performed Now let’s see the tabular column below.
In the first column I took all the conditions and actions related to the requirement. All the other columns represent Test Cases.
T = True, F = False, X = Not possible
From the case 3 and case 4, we could identify that if condition 2 failed then system will execute Action 3. So we could take either of case 3 or case 4
So finally concluding with the below tabular column.
We write 4 test cases for this requirement.
Take another example – login page validation. Allow user to login only when both the ‘User ID’ and ‘Password’ are entered correct.
Here the Conditions to allow user to login are Enter Valid User Name and Enter Valid Password.
The Actions performed are Displaying home page and Displaying an error message that User ID or Password is wrong.
From the case 2 and case 3, we could identify that if one of the condition failed then the system will display an error message as Invalid User Credentials.
So I am eliminating one of the test case from case 2 and case 3 and concluding with the below tabular column.
Sate transition Testing:
This technique is used where some aspect of the system can be described in what is called a “finite state machine”. This simply means that the system can be in a (finite) number of different states, and the transitions from one state to another are determined by the rules of the “machine”.
This model is applied when an application where we need to test different system transitions. We can apply this when an application gives a different output for the same input, depending on what has happened in the earlier state.
Some examples are Vending Machine, Traffic Lights.
- Vending machine dispenses products when the proper combination of coins is deposited.
- Traffic Lights will change sequence when cars are moving / waiting
Example: Take an example of login page of an application which locks the user name after three wrong attempts of password.
A finite state system is often shown as a state diagram:
It works like a truth table. First determine the states, input data and output data.
Entering correct password in the first attempt or second attempt or third attempt, user will be redirected to the home page (i.e., State – S4).
Entering incorrect correct password in the first attempt, a message will be displayed as try again and user will be redirected to state S2 for the second attempt.
Entering incorrect correct password in the second attempt, a message will be displayed as try again and user will be redirected to state S3 for the third attempt.
Entering incorrect correct password in the third attempt, user will be redirected to state S5 and a message will be displayed as “Account locked. Consult Administrator”.
Likewise, let’s see another example:
Withdrawal of money from ATM. ‘User A’ wants to withdraw 30,000 from ATM. Imagine he could take 10,000 per transaction and total balance available in the account is 25,000. In the first two attempts, he could withdraw money. Whereas in the third attempt, ATM shows a message as “Insufficient balance, contact Bank”. Same Action but due to change in the state, he couldn’t withdraw the money in the third transaction.
Use Case Testing:
• In Use Case Testing Test Cases are designed to execute User Scenarios or Business Scenarios.
• A Use Case describes interactions between actors, including users and the system.
• A Use case usually has a mainstream scenario and sometimes alternative scenarios.
Example: Business Scenario: ATM Cash Withdrawal operation
Mainstream Scenario:
1)
User: Inserts ATM Card
System: Asks for PIN
2)
User: Enters PIN
System: Validates PIN and asks to select language
3)
User: Selects Language
System: Asks to select Account Type
4)
User: Selects Account Type
System: Asks to enter Amount
5)
User: Enters Amount
System: Releases Money
Alternatives
2a) Suppose if user enters invalid Pin
System: Shows error message and asks to enter correct PIN
User: Enters Correct PIN
4a) Suppose if user selects incorrect Account Type
System: Shows error and asks to select correct Account Type
User: Select correct account type
5a) If User enters incorrect amount (More than the balance amount or more than the day limit)
System: Shows Error message and asks to enter correct amount
User: Enters correct amount
