What’s In the Black Box?

You are here

black boxBBT

As you could have guessed from the name Black box Testing is thinking of the system as of a black box. This approach means that the tester is not using precise knowledge of the code’s internal structure. It is all about focusing on the system as on something whole, complete. BBT is also often confused with behavioral testing. They are indeed very much alike with one slight difference. Behavioral testing does not encourage testers with knowledge of internal structure, yet it is not as strict as BBT in forbidding it.

And, as we all know each method has its own pros and minuses. Majority of apps is being tested with various methods due to the fact that there’s no ultimate bug-finding thing that would work with 100% accuracy. So where can we find BBT? On Unit, System, Integration, Acceptance and Regression testing stages.

Tools from the box

Testers mostly use all sorts of recording and back-playing tools while performing BBT. They usually record scripts in Java, Perl, VB or TSL. The tools are mostly used for regression testing in order to find out if the new build code caused any bugs in the previous and properly functioning parts. I won’t be mentioning all names and brands of tools because lots of good ones are open source and easy to find.

BBT methods

  • Error guessing. The art of a tester. A masterpiece of intuition. This method is based specifically on the tester’s previous experiences and knowledge. Some QA engineers try to guess in which parts of the code bugs can be hidden. This one does not require tools or can’t be test-cased properly from the beginning to the end.
  • Testing based on graphs. All apps existing consist of various objects. So this method includes a graph with all the app’s parts identified and included. Then you can write test cases, because you now know the relations of every object.
  • Equivalence partitioning. To fulfill this you need to divide the input domain into smaller pieces of classes of data. Then you are free to derive test cases from them.
  • Comparison testing. As it figures from the name all you need to do is compare. Compare different individual parts of code or the whole product.
  • Analysis of Boundary Values. I’d bet you have faced lots of systems fail on boundary. That’s why valuing it is important for the app. So the BVA (Boundary Value Analysis) chooses extreme boundary values. They include typical and error values, inside and outside boundaries, maximum and minimum. Yet BVA is one more interesting topic I would like to write about in a separate article, due to the fact it will take lots of time and space. Would you, my dear readers, enjoy such a “part two” of a sort?

When black is strong…

  • Testers are allowed to be non-technical
  • Actual system with all its specifications can be tested and verified
  • Pretty fast design of test cases: as soon as all the functional specifications are done with

When black is weak…

  • Test inputs require large sample space
  • Writing test cases is hard and painfully slow due to identification of all inputs possible and a lack of time for that
  • The possibility of finding yourself standing on an unidentified path during testing is pretty high