Black box testing methods without knowledge

Question

I stumbled upon some black box techniques (1), but I don't really get how it works. I found sources saying that black box techniques are techniques in which you input something in a program and check if the output matches with the wanted result, if it doesn't, there's an error somewhere.

The source mentioned above says there are techniques, of which the cause-effect or root-effect, the equivalent partitioning and the boundary value analysis are three.

How can a software tester without any knowledge of the program do these tests? To partition it right, I guess you should have knowledge about the program, which especially seems to be the case in the cause-effect technique. Am I misunderstanding some definitions? Can you tell me how this works?

Answer 1

I stumbled upon some black box techniques, but I don't really get how it works. I found sources saying that black box techniques are techniques in which you input something in a program and check if the output matches with the wanted result, if it doesn't, there's an error somewhere.

Let's help with the terminology first:

• Black Box Testing typically means testing the application without knowledge of the internal code (structures, workings, etc). 1
  • Black Box Testing get it's name from Black Box devices.
• When I think of Test Techniques I think of ways design, run and interpret the results of tests.
  • That would make Black Box techniques, test techniques commonly used in a black box approach.
• Knowing if an output is correct requires you to have an Oracle, or a something that helps us decide if the program passed or failed the test. It could be a specification, a reference program, etc.

How can a software tester without any knowledge of the program do these tests?

That would be knowledge of the code, not knowledge of the program.

For example, if we take a look at the test technique Domain Testing, also known as Boundary Analysis and Equivalence Class Partition, and if we use the Schema laid out in the awesome book The Domain Testing Workbook by Cem Kaner the first thing we do is Characterize the Variable.

There's a lot to this but let me see if I can sum it up:

• We look at a program (from a black box perspective) for variables (things we can change) and make a list of all of the interesting ones
• Then we analyze a few interesting variables to understand them by their data type, range of valid values, special cases, responses to invalid values, etc, etc.
• Then we try to understand it's primary dimension or it's primary purpose

It goes on from there until we are able to select a few powerful tests, all without knowing or using knowledge of the internal code.

It's worth noting that many test techniques can be approached from both black box and glass box (or white box) ways.

Answer 2

In black box test a tester should know the expected output depending on input. A tester shouldn't know how the program under test achieves this result (a tester may know it of course but it's not necessary). That is why it's called "black box" - you do not see what going on inside the box (program).

Quotation from your linked source:

Black box testing is testing software based on output requirements and without any knowledge of the internal structure or coding in the program.

In blackbox testing you as a tester should base your tests on the software specification, not on its code! If the specs say "The program should print Good night between 9 PM and 7 AM and Hello! between 7 AM and 9 PM" you make two test cases: time is between 7 AM and 9 PM and time is between 9 PM and 7 AM (for simplicity we don't take boundaries into account here). You don't care whether the programmer coded it with a single if-statement or with a whole bunch of switch-case statements for every single minute of the day (and this would end up in 1440(!) test cases for you if you would base your tests on the code - one test case for every case-branch).