I don't understand integration testing. Is it black box or white box?
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
Ironically, I think it was another question that had the term "integration testing" in it that lead me to write about how testing labels such as integration testing, unit testing, system testing, and acceptance testing often get in the way of talking about testing. They mean different things to different people.
Integration testing can be either black box or white box testing. Black box testing is testing where the person designing the test has no (or very little) internal knowledge of the system they are testing. White box testing, also known as glass box or clear box testing, is testing that takes place where the tester has working knowledge of the code, technology, and architecture. The distinction between the two is one of tester knowledge.
Integration testing is about two parts of the system coming together and testing to ensure there are no "disagreements" between those two parts. The focus in integration testing is more about an idea of risk (the risk of disagreement between systems) than it is about tester knowledge. I can run an integration test as a white box test (testing how two Web services integrate by looking at their message model and how they persist data once they get it) or a black box test (testing how a new version of Adobe Acrobat integrates with the new version of FireFox -– both of which I have no idea how they work).
For more on integration testing, see a similar question I answered about how to approach integration testing and one that John Overbaugh answered about how to do integration testing.
| The distinction between black box testing and white box testing is one of tester knowledge. |
Integration testing is about two parts of the system coming together and testing to ensure there are no "disagreements" between those two parts. The focus in integration testing is more about an idea of risk (the risk of disagreement between systems) than it is about tester knowledge. I can run an integration test as a white box test (testing how two Web services integrate by looking at their message model and how they persist data once they get it) or a black box test (testing how a new version of Adobe Acrobat integrates with the new version of FireFox -– both of which I have no idea how they work).
For more on integration testing, see a similar question I answered about how to approach integration testing and one that John Overbaugh answered about how to do integration testing.
This was first published in November 2008