Black Box Testing-Defination,tools used,methods

Black Box Testing

Black Box Testing, also known as Behavioural Testing, is a software testing method in which the internal structure/design/implementation of the item being tested is not known to the tester. Just giving the input and checking for correct output. These tests can be functional or non-functional, though usually functional.

This method is named so because the software program, in the eyes of the tester, is like a black box; inside which one cannot see.

This method of attempts to find errors in the following categories:

• Incorrect or missing functions
• Interface errors
• Errors in data structures or external database access
• Behavior or performance errors
• Initialization and termination errors

Tools used for Black Box testing:
Black box testing tools are mainly record and playback tools. These tools are used for regression testing that to check whether new build has created any bug in previous working application functionality. These record and playback tools records test cases in the form of some scripts like TSL, VB script, Java script, Perl.

Advantages	Disadvantages
Well suited and efficient for large code segments. Code Access not required. Clearly separates user's perspective from the developer's perspective through visibly defined roles. Large numbers of moderately skilled testers can test the application with no knowledge of implementation, programming language or operating systems.	Limited Coverage since only a selected number of test scenarios are actually performed. Inefficient testing, due to the fact that the tester only has limited knowledge about an application. Blind Coverage, since the tester cannot target specific code segments or error prone areas. The test cases are difficult to design.

Methods of Black box Testing:

1. Equivalence Partitioning:
Equivalence partitioning is a black box testing method that divides the input domain of a program into classes of data from which test cases can be derived.

How is this partitioning performed while testing:
1. If an input condition specifies a range, one valid and one two invalid classes are defined.
2. If an input condition requires a specific value, one valid and two invalid equivalence classes are defined.
3. If an input condition specifies a member of a set, one valid and one invalid equivalence class is defined.
4. If an input condition is Boolean, one valid and one invalid class is defined.

2. Boundary Value Analysis:
Many systems have tendency to fail on boundary. So testing boundary values of application is important. Boundary Value Analysis (BVA) is a test Functional Testing technique where the extreme boundary values are chosen. Boundary values include maximum, minimum, just inside/outside boundaries, typical values, and error values.

Extends equivalence partitioning
Test both sides of each boundary
Look at output boundaries for test cases too
Test min, min-1, max, max+1, typical values

BVA techniques:
1. Number of variables
For n variables: BVA yields 4n + 1 test cases.
2. Kinds of ranges
Generalizing ranges depends on the nature or type of variables
Advantages of Boundary Value Analysis
1. Robustness Testing – Boundary Value Analysis plus values that go beyond the limits
2. Min – 1, Min, Min +1, Nom, Max -1, Max, Max +1
3. Forces attention to exception handling

Limitations of Boundary Value Analysis
Boundary value testing is efficient only for variables of fixed values i.e boundary.

Error Guessing

Error Guessing is a software testing technique that generates test cases which can find the error by using past experience of tester. The key concept is using the prior software testing experience to supplement other software testing techniques. 

The known error in any software is varied so using input from experienced tester for that software is a good idea. From my software testing experience, the typical errors are related to "divide by zero" and "various date and time format".

Software Testing Methods

Different Methods used in Software Testing

Black Box Testing

The technique of testing without having any knowledge of the interior workings of the application is Black Box testing.

This is also known as IO driven testing / behaviour method of testing.

Different Methods of Black Box Testing: I have just mentioned names of Methods of BBT here, I have written it in next post in detail.

1.     Equivalent portioning

2.     Boundary value Analysis

3.     Error Guessing

4.     Graph based

5.     State transition Method

I have posted all BBT methods, advantages, disadvantages, tools used in Black box Testing Post.

White Box Testing

White box testing is the detailed investigation of internal logic and structure of the code. White box testing is also called glass testing or open box testing. In order to perform white box testing on an application, the tester needs to possess knowledge of the internal working of the code.

It is also known as structural testing.

Different Methods of White Box Testing: I have just mentioned names of methods of WBT here, I have written it in next post in detail.

1.     Statement Coverage

2.     Branch Coverage

3.     Path Coverage

4.     Condition Coverage

I have posted all WBT methods, advantages, disadvantages, tools used in Black box Testing Post.

Grey Box Testing

Grey Box testing is a technique to test the application with limited knowledge of the internal workings of an application. In software testing, the term the more you know the better carries a lot of weight when testing an application.

Mastering the domain of a system always gives the tester an edge over someone with limited domain knowledge. Unlike black box testing, where the tester only tests the application's user interface, in grey box testing, the tester has access to design documents and the database. Having this knowledge, the tester is able to better prepare test data and test scenarios when making the test plan.

Advantages

Disadvantages

Offers combined benefits of black box and white box testing wherever possible. Grey box testers don't rely on the source code; instead they rely on interface definition and functional specifications. Based on the limited information available, a grey box tester can design excellent test scenarios especially around communication protocols and data type handling. The test is done from the point of view of the user and not the designer.

Since the access to source code is not available, the ability to go over the code and test coverage is limited. The tests can be redundant if the software designer has already run a test case. Testing every possible input stream is unrealistic because it would take an unreasonable amount of time; therefore, many program paths will go untested.

Black Box vs Grey Box vs White Box

S.N.	Black Box Testing	Grey Box Testing	White Box Testing
1	The Internal Workings of an application are not required to be known	Somewhat knowledge of the internal workings are known	Tester has full knowledge of the Internal workings of the application
2	Also known as closed box testing, data driven testing and functional testing	Another term for grey box testing is translucent testing as the tester has limited knowledge of the insides of the application	Also known as clear box testing, structural testing or code based testing
3	Performed by end users and also by testers and developers	Performed by end users and also by testers and developers	Normally done by testers and developers
4	Testing is based on external expectations - Internal behavior of the application is unknown	Testing is done on the basis of high level database diagrams and data flow diagrams	Internal workings are fully known and the tester can design test data accordingly
5	This is the least time consuming and exhaustive	Partly time consuming and exhaustive	The most exhaustive and time consuming type of testing
6	Not suited to algorithm testing	Not suited to algorithm testing	Suited for algorithm testing
7	This can only be done by trial and error method	Data domains and Internal boundaries can be tested, if known	Data domains and Internal boundaries can be better tested

Defect Life Cycle

Defect Life Cycle (Bug Life cycle/Error Life Cycle) is the journey of a defect from its identification to its closure. The Life Cycle varies from organization to organization and is governed by the software testing process the organization or project follows and/or the Defect tracking tool being used.

Description of Various Stages:

• New : Tester found new bug and report it to test lead.
• Open : Test lead open this bug and assign it to the developer.
• Assign : Developer has three choices after assigning the bug.
• Reject :He can say that this is not a bug because of some hardware or other problems you might getting defect in application..
• Differed : He can postpone bug fixing according to priority of bug.
• Duplicate : If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “DUPLICATE”.
• Fixed : If there are no such conditions like reject, duplicate the developer has to fix the bug.
• Testing : Test the whole application to find the defects if the defect is still there they will re-open the bug and if bug is not there it will move to verify.
• Re-open : If defect raised during testing we re-open bug.
• Verify : Retest whole application.
• Close : Close the application.                                                               

• Status	Alternative Status
  NEW
  ASSIGNED	OPEN
  DEFERRED
  DROPPED	REJECTED
  COMPLETED	FIXED, RESOLVED, TEST
  REASSIGNED	REOPENED
  CLOSED	VERIFIED