Black box test Design Techniques

Black Box Test Design Techniques

Software Test Design Techniques

Test Design technique is a process to identify few test cases out of many with the likelihood of identifying defects. It helps to achieve high test coverage.

Black box or Specification Based Techniques

Specification-based technique is used to discover what claims are made in the specifications and testing the software against them. It is also known as Black box or Input/output driven testing techniques. Specification based test techniques are based upon the test conditions and test cases derived from the SRS documents.

Types of Black box testing techniques

1)    Equivalence classes
2)    Boundary Value Analysis
3)    Decision Table Testing
4)    State Transition Testing
5)    Use Case Testing

1)    Equivalence classes

Equivalence class is a method of deriving a set of test cases from different classes of test cases.
Identify all possible test cases to validate functionality in the system and then segregate those Test cases into classes or groups. Ensure that all the Test cases under a class produce same output and select one test case from each class. This method can be used for both valid data and invalid data and it is applicable at all levels of testing.

Example:

We have to test an input text box that should accept a 10 digit mobile number.
In this scenario we could not test every data like numeric, alphabets, alpha numeric, special characters and combination of alpha numeric and special characters.
Here we can use Equivalence class technique to identify test cases.
We can divide as classes or groups like

I.    Only Numeric
II.    Only Alphabets
III.    Alpha Numeric
IV.    Special Characters
V.    Alpha numeric and Special Characters
From each class we can select any test data randomly and use for testing.

2)    Boundary value analysis

Boundary value is testing boundaries between Equivalence partitions.
It include testing maximum, minimum, just inside boundaries, just outside boundaries, typical values and error values.  It is relatively easy to apply and its defect-finding capability is high. This technique can be applied at all test levels.

Example:
Considering the same example of equivalence classes, we can select boundary value test cases also.

BVA Test cases could be
I.    Selecting a single digit value (minimum)
II.    Selecting a 10 digit value (maximum)
III.    Selecting a 9 digit value (Just inside boundary)
IV.    Selecting a 11 digit value (Just outside boundary)

3)    Decision table testing

Decision table testing is used to test the combination of inputs that produce different results. This technique is sometimes also referred to as a ‘Cause-effect’ table.
When creating decision tables, the specification is analyzed, and then conditions and actions of the system are identified. The input conditions and actions are most often stated in such a way that they must be true or false (Boolean). The strength of decision table testing is that it creates combinations of conditions that otherwise might not have been exercised during testing.

Example:

If you are a new customer and you want to open a credit card account then there are three conditions first you will get a 15% discount on all your purchases today, second if you are an existing customer and you hold a loyalty card, you get a 10% discount and third if you have a coupon, you can get 20% off today (but it can’t be used with the ‘new customer’ discount). Discount amounts are added, if applicable. This is shown in below Table
Decision table for credit card example

 Conditions Rule 1 Rule 2 Rule 3 Rule 4 Rule 5 Rule 6 Rule 7 Rule 8 New Customer (15%) T T T T F F F F Loyalty card (10%) T T F F T T F F Coupon (20%) T F T F T F T F Actions Discount (%) X X 20 15 30 10 20 0

In the above table, the conditions and actions are listed in the left hand column. All the other columns in the decision table each represent a separate rule, one for each combination of conditions. We may choose to test each rule/combination and if there are only a few this will usually be the case. However, if the number of rules/combinations is large we are more likely to sample them by selecting a rich subset for testing.

Now let’s see the decision table for credit card shown above:
•    Note that we have put X for the discount for two of the columns (Rules 1 and 2) – this means that this combination should not occur. You cannot be both a new customer and also holding a loyalty card as per the conditions mentioned above. Hence there should be an error message stating this.
•    We have made an assumption in Rule 3. Since the coupon has a greater discount than the new customer discount, we assume that the customer will choose 20% rather than 15%. We cannot add them, since the coupon cannot be used with the ‘new customer’ discount as stated in the condition above. The 20% action is an assumption on our part, and we should check that this assumption (and any other assumptions that we make) is correct, by asking the person who wrote the specification or the users.
•    For Rule 5, however, we can add the discounts; since both the coupon and the loyalty card discount should apply (that’s our assumption).
•    Rules 4, 6 and 7 have only one type of discount and Rule 8 has no discount, so 0%.
The advantage of doing this is that we may test a combination of things that otherwise we might not have tested and that could find a defect.

4)    State Transition testing

State transition testing is used where some aspect of the system can be described in what is called a ‘finite state machine’. It allows the tester to view the software in terms of its states, transitions between states, the inputs or events that trigger changes in state (transitions) and the actions which may result from those transitions.
The process for State transition testing is to draw state transition diagram
i.    Determine start state, input, output and finish state
ii.    Determine coverage level to be achieved
iii.    Draw testing tree
iv.    Define tests

Example:

You have a balance of Rs.15,000/- in your account, and if you request to withdraw Rs.10,000/- from a bank ATM, you may be given cash . Later if you make exactly the same request but it may refuse to give you the money because of insufficient balance (Rs.5,000/-). This later refusal is because the state of your bank account has changed from having sufficient funds to cover the withdrawal to having insufficient funds. The transaction that caused your account to change its state was probably the earlier withdrawal.

5)    Use case testing

Use case testing is a technique that helps to understand business conditions and flows. It is used to identify test cases that exercise the whole system on a transaction by transaction basis from start to finish.
Use case testing describes interactions between actors, including users and the system, which produce a result of value to a system user. Use cases are a sequence of steps that describe the interactions between the actor and the system.

Example:

The ATM PIN example is shown below.
In this we can see the interactions between the A (actor – in this case it is a human being) and S (system).
From step 1 to step 5 that is success scenario it shows that the card and pin both got validated and allows Actor to access the account.
But in extensions there can be three other cases that is 2a, 4a, 4b which is shown in the diagram below.

Main Success Scenario
A: Actor
S: System    Step    Description
1    A: Inserts card
2    S: Validates card and asks for PIN
3    A: Enters PIN
4    S: Validates PIN