white box black box 5 December, 2006 at 12:36 pm
so, there are two general mechanisms for testing:
blackbox is what most users are aware of. You put stuff into the magic black box and answers come out. you don’t care how it gets from A to B, as long as B is what it’s supposed to be
whitebox is the developers mechanism. you put A in, then you follow it through the code/pipes/innards and verify that at each step it’s the B it’s supposed to be. then at the end you get the answer. it’s called “white box testing” because it’s the opposite of “black box”. It’s also called “clear box” or “no box”; the idea being that black-box is big, black, and completely hides the internal workings. whitebox lets you see the insides
whitebox is basically used in debugging code. because if you put in A and get Z, you know there was a problem, so you trace it through A B C F … and you know where to look to fix it.
right now i’m debugging an app we’re upgrading. and i get to do it through blackbox debugging. I put stuff in, and see what comes out. I can’t fix anything, but I keep narrowing down where the problem is. As I find a case that doesn’t work (A53), I then narrow it down further to find the minimum required “bad A” that triggers the problem. it’s a real pain in my ass, and it sucks.
there’s a reason why no one uses black box debugging. IT SUCKS! *sigh*
be lucky you’re not doing Stratics debugging…
“Um, this broke.”
“Okay.”
*two years pass*
“Um, this is still broke.”
“Okay. SMS is GOD!! It will work then.”
they’re still on about sms? it isn’t done yet?
are we still regressing and every time you ask it gets less done?
sad sad sad
SMS doesn’t have to be done. It just IS!