White Box Testing

White-box testing is concerned with testing, the implementation of the program. The intent of this testing is not to exercise all the different input or output conditions but to exercise the different programming structures and data structures used in the program.

White-box testing is also called as Structural Testing or Glass box testing. It is a good practice to perform white box testing during the unit testing phase.

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.

Testing Web Applications

Web Application can have thousands of users than a conventional, non-Web Application. Web Application checklist is as follows:-

    Functionality Testing.
    Usability testing.
    Interface testing.
    Compatibility testing.
    Performance testing.
    Security testing.

Test all the Links in web pages.

Test the particulars like:-

    Test the outgoing links from all the pages.
    Test all internal links.
    Test links on the same pages.
    Test links used to send the email to admin or other users from web pages.
    Test to check if there are any orphan pages.
    Test the Anchor text links.

Test Database:-
 
Data consistency is very important in web application.
 
Check for data integrity.
    Errors while doing Database functionality like Editing, Deleting, Inserting, Modifying the forms.

Test the Cookies:-

    Test the application by enabling or disabling the cookies.
    Test the session cookies check for login sessions and user status after session ends.
    Check effect on application security by deleting the cookies.

Test the Content:-

    Content should be logical and easy to understand.
    Check for spelling errors.
    Use of dark colors annoys for font, frames etc...
    All the anchor text links should be working properly.
    Images should be placed properly with proper sizes.

Test Interfaces:-

    Check if all the interactions between these servers are executed properly.
    Errors are handled properly.
    Check what happens if user interrupts any transaction in-between?
    Check what happens if connection to web server is reset in between?

Test application performance:-
    Load Testing.
    Stress Testing.

Test for Security:-

    Test by pasting internal URL directly into browser address bar.
    Try directly changing the URL site ID parameter to different site ID which is not related to log in user.
    Try some invalid inputs in input fields.

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).