Black Box Testing: Types and techniques of BBT

Black box testing treats the system as a “black-box”, so it doesn’t explicitly use Knowledge of the internal structure or code. Or in other words the Test engineer need not know the internal working of the “Black box” or application.

Main focus in black box testing is on functionality of the system as a whole. The term ‘behavioral testing’ is also used for black box testing and white box testing is also sometimes called ‘structural testing’. Behavioral test design is slightly different from black-box test design because the use of internal knowledge isn’t strictly forbidden, but it’s still discouraged.

Each testing method has its own advantages and disadvantages. There are some bugs that cannot be found using only black box or only white box. Majority of the application are tested by black box testing method. We need to cover majority of test cases so that most of the bugs will get discovered by black box testing.

Black box testing occurs throughout the software development and Testing life cycle i.e in Unit, Integration, System, Acceptance and regression testing stages.

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 of Black Box Testing

•         Tester can be non-technical.
•          Used to verify contradictions in actual system and the specifications.
•          Test cases can be designed as soon as the functional specifications are complete

Disadvantages of Black Box Testing

•         The test inputs needs to be from large sample space.
•         It is difficult to identify all possible inputs in limited testing time. So writing test cases is slow and difficult
•         Chances of having unidentified paths during this testing

Methods of Black box Testing:

Graph Based Testing Methods:

Each and every application is build up of some objects. All such objects are identified and graph is prepared. From this object graph each object relationship is identified and test cases written accordingly to discover the errors.

Error Guessing:

This is purely based on previous experience and judgment of tester. Error Guessing is the art of guessing where errors can be hidden. For this technique there are no specific tools, writing the test cases that cover all the application paths.

Boundary Value Analysis:

Many systems have tendency to fail on boundary. So testing boundry 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

• -          Robustness Testing – Boundary Value Analysis plus values that go beyond the limits
• -          Min – 1, Min, Min +1, Nom, Max -1, Max, Max +1
• -          Forces attention to exception handling

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

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:

•          If an input condition specifies a range, one valid and one two invalid classes are defined.
•          If an input condition requires a specific value, one valid and two invalid equivalence classes are defined.
•          If an input condition specifies a member of a set, one valid and one invalid equivalence class is defined.
•          If an input condition is Boolean, one valid and one invalid class is defined.

Comparison Testing:

Different independent versions of same software are used to compare to each other for testing in this method.

Security testing checklist

Security testing checklist is a very powerful fact-gathering tool deployed to ensure that our new web application behaves as expected from security related considerations.

Sr.	Check Point	Yes/No
Check Points related to Data Security
1.	Are data inputs adequately filtered?
2.	Are data access privileges identified? (e.g., read, write, update and query)
3.	Are data access privileges enforced?
4.	Have data backup and restore processes been defined?
5.	Have data backup and restore processes been tested?
6.	Have file permissions been established?
7.	Have file permissions been tested?
8.	Have sensitive and critical data been allocated to secure locations?
9.	Have date archival and retrieval procedures been defined?
10.	Have date archival and retrieval procedures been tested?
Check Points related to Data Encryption
1.	Are encryption systems / levels defined?
2.	Is there a standard of what is to be encrypted?
3.	Are customers compatible in terms of encryption levels and protocols?
4.	Are encryption techniques for transactions being used for secured transactions? - Secure socket layer (SSL) - Virtual Private Networks (VPNs)
5.	Have the encryption processes and standards been documented?
Check Points related to Disaster Recovery
1.	Have service levels been defined. (E.g., how long should recovery take?)
2.	Are fail-over solutions needed?
3.	Is there a way to reroute to another server in the event of a site crash?
4.	Are executables, data, and content backed up on a defined interval appropriate for the level of risk?
5.	Are disaster recovery process & procedures defined in writing? If so, are they current?
6.	Have recovery procedures been tested?
7.	Are site assets adequately Insured?
8.	Is a third party "hot-site' available for emergency recovery?
9.	Has a Business Contingency Plan been developed to maintain the business while the site is being restored?
10.	Have all levels in organization gone through the needed training & drills?
11.	Do support notification procedures exist & are they followed?
12.	Do support notification procedures support a 24/7 operation?
13.	Have criteria been defined to evaluation recovery completion / correctness?

Difference between Black Box, Gray Box and White Box Testing

Sr	Black Box Testing	Gray Box Testing	White Box Testing
1	Low granularity	Medium granularity	High granularity.
2	Internals NOT known.	Internals partially known.	Internals fully known.
3	Internals not required to be known.	Internals relevant to testing are known.	Internal code of the application and database known.
4	Also known as # Opaque box testing # Closed box testing # Input output testing # Data driven testing # Behavioral testing # Functional testing	Also known as  Translucent box testing.	Also known as # Glass box testing # Clear box testing # Design based testing # Logic based testing # Structural testing # Code based testing.
5	It is done by end-users (User acceptance testing). Also done by testers & developers.	It is done by end-users (user acceptance testing).  Also done by testers & developers.	It is normally done by testers  & developers.
6	Testing method where # System is viewed as a black box #  Internal behavior of the program is ignored # Testing is based upon external specifications.	Internals are partly known (i.e. gray), but not fully known (i.e. white).  Test design is based on the knowledge of the algorithm, interval states, architecture or other high level descriptions of the program behavior.	Internals are fully known.
7	It is likely to be least exhaustive of the three.	It is somewhere in between.	Potentially most exhaustive of the three.
8	Requirements based. Test cases based on the functional specifications, as internals not known.	Better variety / depth in test cases on account of high level knowledge of internals.	Ability to exercise code with relevant variety of data.
9	Being specification based if would not suffer from the deficiency as described for white box testing.	It would also not suffer from the deficiency as described for white box testing.	Since test cases are written based on the code, specifications missed out in coding would not be revealed.
10	It is suited for functional / business domain testing.	It is suited for functional / business domain testing bit in depth.	It is suited for all.
11	Not suited to algorithm testing.	Not suited to algorithm testing.	Appropriate for algorithm testing.
12	It is concerned with validating outputs for given inputs, the application being, treated as a black box.	Here in, we have a better variety of inputs and the ability to extract test results from database for comparison with expected results.	It facilitates structural testing. It enables logic coverage, coverage of statements, decisions, conditions, path and control flow within the code.
13	It can test only by trial and error (data domains, internal boundaries and overflow.	It can test data domains, internal boundaries and overflow, if known.	It can determine and therefore test better: data domains, internal boundaries and overflow.