Re: (OT) Black- vs. white-box testing

[pg]

"In legacy code, the interface may be the implementation, but that does not mean that one is necessarily white-box testing."

It is interesting that "white-box testing" suddenly showed up.

I think there is a mix up. The way you test something has absolutely nothing to do with how it is spec'd out, or how it is implemented. The tester has a choice.

As for white box and black box. Let's use maze as an example to explain this. If you draw your maze on a piece of paper, when I look at that piece of paper, I see a white box. If I am going through a real hay maze, I am seeing a black box.

[Anonymous Monk]

As for white box and black box. Let's use maze as an example to explain this. If you draw your maze on a piece of paper, when I look at that piece of paper, I see a white box. If I am going through a real hay maze, I am seeing a black box.

No, white box testing is the map of all the distinct entrances and exits; you verify that each entrance leads to the correct exit, and that if you follow the right path, you'll come out in the right place. You're making sure that the design of the maze looks good, by looking at an arial map or satelite photo.

Black box testing is like standing there with a clipboard and noting: "Bill went in exit A, and came out exit B. Check! Sally went in entrance B, and came out exit D. Check! Fred went in entrace C, we heard loud screaming, and then silence. Hmm... the system appears to ocassionally hang when entrance C is used, especially when the input person enters carrying buckets of blood or raw steaks... interesting..."

Debugging is actually wandering through the actual maze, in order to hunt down the monsters inside. Overflying the maze with a helicopter and a shotgun is using "perl -d". :-)