DEFINITION
Black Box Testing, also known as Behavioral Testing, is a software testing method in which the internal structure/design/implementation of the item being tested is not known to the tester. These tests can be functional or non-functional, though usually functional.
Black Box Testing method is named so because the software program, in the eyes of the tester, is like a black box; inside which one cannot see.
Black Box Testing is contrasted with White Box Testing. View Differences between Black Box Testing and White Box Testing.
- Incorrect or missing functions
- Interface errors
- Errors in data structures or external database access
- Behavior or performance errors
- Initialization and termination errors
A tester, without knowledge of the internal structures of a website, tests the web pages by using a browser; providing inputs (clicks, keystrokes) and verifying the outputs against the expected outcome.
LEVELS APPLICABLE TO
Black Box Testing method is applicable to all levels of the software testing process:
- Unit Testing
- Integration Testing
- System Testing
- Acceptance Testing
TEST DESIGN TECHNIQUES
Equivalence partitioning
Equivalence Partitioning is a software test design technique that involves dividing input values into valid and invalid partitions and selecting representative values from each partition as test data.
Boundary Value Analysis
Boundary Value Analysis is a software test design technique that involves determination of boundaries for input values and selecting values that are at the boundaries and just inside/outside of the boundaries as test data.
Cause Effect Graphing
Cause Effect Graphing is a software test design technique that involves identifying the cases (input conditions) and effects (output conditions), producing a Cause-Effect Graph, and generating test cases accordingly.
ADVANTAGES OF BLACK BOX TESTING
- Tests are done from a user's point of view and will help in exposing discrepancies in the specifications
- Tester need not know programming languages or how the software has been implemented
- Tests can be conducted by a body independent from the developers, allowing for an objective perspective and the avoidance of developer-bias
- Test cases can be designed as soon as the specifications are complete
- Only a small number of possible inputs can be tested and many program paths will be left untested
- Without clear specifications, which is the situation in many projects, test cases will be difficult to design
- Tests can be redundant if the software designer/ developer has already run a test case.
2 comments:
I had a nice discussion with JakeBrake at SQAforums regarding Black Box Testing, and I have placed the excerpt below for your reference. JakeBrake, my apologies for posting the excerpts here without your consent. I was not allowed to send a private message to you since I had not made 35 posts in the forum. I will however reach that number soon and be in touch with you.
________________________
JakeBrake:
I think you need to accommodate the fact that many would not agree with this:
- Black Box Testing method is applicable to all levels of the software testing process: Unit Testing
- Only a small number of possible inputs can be tested and many program paths will be left untested
________________________
Preston:
JakeBrake, thank you for your comments. I have seen unit tests being conducted using the black box method, though i admit this is very rare. Obviously, it is more applicable to higher levels of testing.
The inability of the black box testing method to actually drill down to all legal and illegal inputs/paths leaves many paths untested. At most, this method can only determine valid and invalid inputs.
________________________
JakeBrake:
Anyways, these advantages and disadvantages issues are always debatable, considering the perspective one takes.
I would refer to this as less-than-robust unit testing. I would suggest that using unit testing and blackbox testing
in the same sentence; the context being unit testing - is at best going to confue the reader.
________________________
Preston:
yes very true, i admit again that i am myself somewhat confused. i have seen some people taking a 'module' of an
application and performing tests on this module using the black box method before integrating all modules and proceeding to upper levels of testing.
unit testing is more robust if white box testing method is used.
is there any standard as to what extent a unit is to be called a unit?
________________________
JakeBrake:
The definition I embraced years ago from a US Dept of Defense standard - paraphrased...
"The smallest chunk of software/code required to implement a function."
________________________
Preston:
thanks, in that case we may need to discourage people from calling 'module' testing, that invariably consists of lots of those chunks and functions, as 'unit' testing.
________________________
JakeBrake:
Definitions are ultimately up to you and your organization. Many regard unit, module, and component as synonymous.
Pick one that many can agree on. When you have agreement, consumers are more likely to have accurate expectations.
________________________
Preston:
thank you so much. i now intend to do more research on each of 'unit', 'module' and 'component' testing, identify subtle differences and try to clarify myself. one thing i am now sure is that i will not be content with all three being synonymous and we need to set many expectations right, as you have stated.
________________________
The sentence "Anyways, these advantages and disadvantages issues are always debatable, considering the perspective one takes." was by Preston. I haven't figured out how to edit my comments in Blogger yet.
Post a Comment