I think this depends on context. Are you finished implementing the specifications mostly and want to begin your final testing or are you speaking of generally anytime during development cycle? As some mention in answers, your implementers will usually write unit tests which can be considered part of your whtie box testing as these coders understand the inner workings and want to assert functionality of their implementation prior to committing.
–
ChrisDec 20 '10 at 12:58

10 Answers
10

Seriously, white-box testing (i.e. testing the internals of code) should ideally be done with unit tests by the developer who wrote the code. Unit tests would be built up over time, and part of the build process so we don't waste the poor tester's time with code we know doesn't work as it should. Unit testing becomes more important the smaller your team is--particularly because you don't have an army of testers to shake problems out.

Black-box testing (i.e. testing through the user/system interface) is typically what most testers do.

All testing needs to be prioritized on how critical a function is for the finished product. If the mission is to provide a tool to do X and the product doesn't do X, that's a big problem.

I'm not sure what you mean by "black box components" and "white box components" - to me they'r just "components" (that can be tested with or without knowledge of the underlying code or architecture.
–
AlanDec 17 '10 at 17:36

I do not understand the "dependent" relationship you are suggesting here. White black and black box are not components, more of a style of testing any component as Alan mentions. The difference is in the approach taken to test the component in question.
–
ChrisDec 20 '10 at 12:55

You first do white testing thinking as a coder/developer to make sure things will work fine.
Then you do black box testing usually trying to think as if you were the end user, without thinking on the internal structure of the program. Sometimes you need to think like a coder/developer even if you are doing a black testing because you might be testing an internal module that was written by another person and you dont have access to the code.

If you want to have a good test cycle, you should have different people doing Both:

A developer focused mainly on white-box testing knows what has changed in the code recently, which areas are more complex (and therefore likely to break), etc and can focus efforts appropriately in these areas most likely to introduce new defects.

On the other hand, a QA tester focused on black-box testing can more easily approach testing like an end user. Without any internal knowledge of the code, they can take a fresh approach and are not biased by the knowledge of how different parts of the solution are implemented. They will catch bugs that the developer may have overlooked, or regressions from code changes that accidentally broke other areas of the application.

To answer your question, the white-box testing should be done first. But you really need to have a different person doing the black box testing if you want to it to be effective.

Black box testing, because you are writing tests before the code exists. The tester needs to be developing time-consuming automatic tests in parallel with the developer writing code to be efficient on a small team.

If the code is already written, I would suggest you spend some time sketching out test coverage from a black-box point of view to make sure you get some time brainstorming before you clutter your brain with the actual code. However, you can then switch to white-box and look at the code before you get too far along with actual testing to get a feel for the risky areas and to prioritize those tests you brainstormed earlier (and augment them with new tests thought up by looking at parts of the code that seem complicated or questionable).

@Ethel Evans: They're not white box tests by definition. The vast majority of unit tests are white box tests, but it's not a requirement. Any tests that map the domain of inputs to the range of outputs of a function are unit tests, but need not know the details of the implementation.
–
Steve EversDec 21 '10 at 19:32

-1, TDD is white box testing. In TDD it is essential to know what the code involved in the test does (and what it does not) to write the next test. Black box testing means that someone who has no idea of the code (a tester, someone who does not even needs to know how to code), designs the tests.
–
Doc BrownMay 17 '14 at 21:31

Then we do not practice TDD the same way. TDD for me is about enforcing the specifications of a class/function: the tests are written to check that the class/function behaves as specified, but could care less how the code behaves behind the scenes so long as those specifications are upheld... which is necessary given that the tests are written before the functionality.
–
Matthieu M.May 18 '14 at 10:54