Black Box Testing

Black-box testing enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for a program. It is a complementary approach that is to uncover the errors. Black-box testing attempts to find the errors in, incorrect missing functions, interface errors, errors in data structures, external data base access, performance error or termination errors.

Black-Box Testing is also called as Behavioral testing. Black-box testing is usually described as focusing on testing functional requirements.

Equivalence Partitioning

Equivalence partitioning (EP) is a black box testing technique. This technique is very common and mostly used by all the testers informally. Equivalence partitions are also known as equivalence class partitioning.

As the name suggests Equivalence partitioning is to divide or to partition a set of test conditions into sets or valid and invalid groups that can be considered same while testing.

For example if you have to test a condition say Age field should only accept a number ranging from 0 and 100. You can't test for each value. As you all know that exhaustive testing of the software is not feasible task. In such cases equivalence partitioning technique is applied. Here the test data would be divided into partitions of valid and invalid range. In our case, valid range would be 0 to 100 and invalid range would be >100 and <0. While testing a data from each class or partition is considered and tested.

State Transition Graphs

State transition testing is used for systems where some aspect of the software system can be described in 'finite state machine'. This 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'.

What is a finite State System?

Any system where you get a different output for the same input, depending on what has happened before is a finite state system. A finite state system is often shown as a state diagram.

Let us take an example to explain this in detail:

Suppose you want to withdraw $500 from a bank ATM, you may be given cash. After some time you again try to withdraw $500 but you may be refused the money (because your account balance is insufficient). This refusal is because your bank account state has changed from having sufficient funds to cover withdrawal to having insufficient funds. The transaction that caused your account to change its state was probably the earlier withdrawal. A state diagram can represent a model from the point of view of the system or the customer.

A state transition model has four basic parts:-

    1.The states that the software may occupy (funded/insufficient funds)
    2.The transitions from one state to another (all transitions are not allowed)
    3.The events that cause a transition (like withdrawing money)
    4.The actions that result from a transition (an error message or being given your cash)

Please note that in any given state, one event can cause only one action, but that the same event from a different state may cause a different action and a different end state.

Decision Table Testing

What is a Decision Table?

It is a table which shows different combination inputs with their associated outputs, this is also known as cause effect table.

In EP and BVA we have seen that these techniques can be applied to only specific conditions or inputs however if we have different inputs which result in different actions being taken or in other words we have a business rule to test where there are different combination of inputs which result in different actions.

For testing such rules or logic decision table testing is used.

It is a black box test design technique.

All Pair Technique

"All Pairs" is a test design technique that can be used when there are several variables to test. The test cases include all the pairs of values for every variable. The output of "All Pairs" technique is that every value is paired with another value at least once.

Here are some examples of testing several variables:

-    A search screen with several search criteria. 
-    Configuration options of software. 
-    Configuration options of hardware. 
-    Compatibility testing across different OS and browser combinations.

"All Pairs" drastically reduces the number of test cases required to test software and it can help you find most errors with the smallest number of test cases.

Example:

Let say, for example, there are 3 parameters that can be given for a search criteria: P1, P2 and P3.

-    P1 can have the values as '10' and '50'.

-    P2 can have the values as 'g' and 'c'.

-    P3 can have the values as 'a' and 'b'.

Step 1 - calculate all combinations

The Cartesian product will be:

P1 X P2 X P3 = {10, 50} X {g, c} X {a, b}

In tabular format:

Test Case #	Values Participates	Result
1	{10, 50}X{g, c}X{a, b}	(10, g, a)
2	{10, 50}X{g, c}X{a, b}	(10, g, b)
3	{10, 50}X{g, c}X{a, b}	(10, c, a)
4	{10, 50}X{g, c}X{a, b}	(10, c, b)
5	{10, 50}X{g, c}X{a, b}	(50, g, a)
6	{10, 50}X{g, c}X{a, b}	(50, g, b)
7	{10, 50}X{g, c}X{a, b}	(50, c, a)
8	{10, 50}X{g, c}X{a, b}	(50, c, b)

Step 2 – base table

Now, let's create a table that each column represents a variable and each row represents a test case combination:

Test Case #	P1	P2	P3
1	10	g	a
2	10	g	b
3	10	c	a
4	10	c	b
5	50	g	a
6	50	g	b
7	50	c	a
8	50	c	b

Step 3 - pick the last row (mark in red):

Test Case #	P1	P2	P3
1	10	g	a
2	10	g	b
3	10	c	a
4	10	c	b
5	50	g	a
6	50	g	b
7	50	c	a
8	50	c	b

Step 4 – If all pairs exist in other rows – delete the last row and go up, if not keep the row and go up to the next row:

Test Case #	P1	P2	P3
1	10	g	a
2	10	g	b
3	10	c	a
4	10	c	b
5	50	g	a
6	50	g	b
7	50	c	a
8	50	c	b

We can see that the pair (50, c) exists in test case 7, the pair (50, b) exists in test case 6 and the pair (t, b) exists in test case 4. Because all pairs in test case 8 (the last row) exists in above rows, we can delete test case 8.

The new table will be:

Test Case #	P1	P2	P3
1	10	g	a
2	10	g	b
3	10	c	a
4	10	c	b
5	50	g	a
6	50	g	b
7	50	c	a

Now, let's move one row up to test case 7:

Test Case #	P1	P2	P3
1	10	g	a
2	10	g	b
3	10	c	a
4	10	c	b
5	50	g	a
6	50	g	b
7	50	c	a

We don’t have the couple (50, b) so we keep the line (test case 6) and move up to the next row up to test case 5.

Test Case #	P1	P2	P3
1	10	g	a
2	10	g	b
3	10	c	a
4	10	c	b
5	50	g	a
6	50	g	b
7	50	c	a

We can see that the pair (50, g) exists in test case 6, the pair (50, a) exists in test case 7 and the pair
(g, a) exists in test case 1. Because all pairs in test case 5 (the current row) exists in other rows, we can delete test case 5.


The new table will be:

Test Case #	P1	P2	P3
1	10	g	a
2	10	g	b
3	10	c	a
4	10	c	b
6	50	g	b
7	50	c	a

Now, let's move one row up to test case 4.

Test Case #	P1	P2	P3
1	10	g	a
2	10	g	b
3	10	c	a
4	10	c	b
6	50	g	b
7	50	c	a

We don’t have the couple (c, b) so we keep the line (test case 4) and move up to the next row up to test case 3:

Test Case #	P1	P2	P3
1	10	g	a
2	10	g	b
3	10	c	a
4	10	c	b
6	50	g	b
7	50	c	a

We can see that the pair (10, a) exists in test case 1, the pair (10, c) exists in test case 4 and the pair (c, a) exists in test case 7. Because all pairs in test case 3 (the current row) exists in other rows, we can delete test case 3.


The new table will be:

Test Case #	P1	P2	P3
1	10	g	a
2	10	g	b
4	10	c	b
6	50	g	b
7	50	c	a

Now, let's move one row up to test case 2:

Test Case #	P1	P2	P3
1	10	g	a
2	10	g	b
4	10	c	b
6	50	g	b
7	50	c	a

We can see that the pair (10, g) exists in test case 1, the pair (10, b) exists in test case 4 and the pair (g, b) exists in test case 6. Because all pairs in test case 2 (the current row) exists in other rows, we can delete test case 2.

The new table will be:

Test Case #	P1	P2	P3
1	10	g	a
4	10	c	b
6	50	g	b
7	50	c	a

Now, let's move one row up to test case 1.

Test Case #	P1	P2	P3
1	10	g	a
4	10	c	b
6	50	g	b
7	50	c	a

We don’t have the couples (10, g), (10, b), (g, b) so we keep the line.

Test Case #	P1	P2	P3
1	10	g	a
4	10	c	b
6	50	g	b
7	50	c	a

Now, no more lines left which means that after using "All Pairs" technique, we have 4 test cases to test. We reduced the number of test cases from 8 to 4 (50% less).

Error Guessing

What is Error Guessing?

This is a Test design technique where the experience of a tester is used to find the components of software where defects might be present.

It is mostly done by experienced tester's who can use their past experience to find defects in software.

Error guessing has no rules for testing, it only uses the tester's previous skills.

In error guessing tester's can think of situations where software will fail.
 
For example:

    1. Division by zero.
    2. Pressing submit button on form without filling any entries.
    3. Entering wring data in the fields and checking software behavior.

Use Case Technique

Before explaining Use case Testing lets first understand what is a Use Case?

1. A Use case is a description of a particular use of the system by the end user of the system.

2. Use cases are a sequence of steps that describe the interactions between the user and the software system.

3. Each use case describes the interactions the end user has with the software system in order to achieve a specific task.

What is Use case Testing?

Use case testing is a technique that helps us identify test cases that exercise the whole system on a transaction by transaction basis from start to finish.

Use cases are defined in terms of the end user and not the system, use case describe what the user does and what the user sees rather than what inputs the software system expects and what the system outputs.

Use cases use the business language rather than technical terms.

Each use case must specify any preconditions that need to be met for the use case to work. Use cases must also specify post conditions that are observable results and a description of the final state of the system after the use case has been executed successfully.

Boundary Value Analysis

A boundary value is a value on the edge of an equivalence partition. Boundary value analysis is all about testing the component at the boundaries.
For example: Consider the same example that is considered for equivalence partitioning.

There is an Age field that should accept a range of values from 0 to 100 only. For this the boundaries would be 0 and 100. Testing at the boundary would yield 3 data values at each end that should be used for testing. So for 0 the boundary the values would be -1, 0 and 1 (It is to have a value less than the boundary value, the boundary value and the next value) and the values for next boundary 100 are 99, 100 and 101

All the 6 values have to be used to test Age field.