On a very small team, where the black box and white box testing is done by the same person, which should the tester do first?

  • 1
    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. – Chris Dec 20 '10 at 12:58

10 Answers 10


Whatever must be most correct.

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.

  • 1
    Well said, best answer I read thus far. – Chris Dec 20 '10 at 12:56


Black-box testing to verify the features. White-box testing as necessary if things are broken. If all the black-box tests pass and the coverage is good, white-box testing is unnecessary.

  • 2
    Unless, of course, the black box tests missed testing a key piece of functionality or configuration :} – Alan Dec 17 '10 at 19:15
  • 4
    @Alan: same argument applies to white-box testing, hence the 'coverage is good' caveat – Steven A. Lowe Dec 17 '10 at 19:21
  • 1
    Agreed - I guess my statement depends on your definition of good coverage. – Alan Dec 17 '10 at 19:36
  • 1
    @DocBrown I absolutely do not see how what you explained is anything remotely like whitebox testing. Whitebox testing is about following the branch paths of a given implementation, and writing test cases that will exercise all paths. If you don't have an implementation yet, then you cannot per definition make whitebox tests. With TDD and BDD you write tests of the general shape given-when-then. You set up the input data or preconditional state, fire the unit, and make checks on the output data, or end state or third party calls. This is the definition of blackbox testing. – Sammi Oct 10 '16 at 13:37
  • 1
    @SamJudge: to my understanding, when you look inside the implementation code and use that information to design very specific test data (which is then passed through the public interface), then it justified to call this white box testing. Such a test also fails if the outcome is not what one expects. If you later look just at the test, you may not be able to say clearly "this test was produced by a white box (or black box) approach", of course. – Doc Brown Nov 29 '18 at 19:39

Black box.

White box components are usually dependent on black box components, so I would want to test the black box first and then move on to the white box.

  • 2
    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. – Alan Dec 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. – Chris Dec 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.


I like to start with black box testing, then use code coverage information or the debugger to figure out what I'm doing and analyze what's happening.

But the real answer is it depends. I'm likely to dive into the code sooner (ore even first) if I'm doing API testing, but much later if my goal is to look at some large end to end scenarios.


I would say Black Box testing first, simply because as a proponent of TDD, the tests are written before the code (or box) exist anyway :)

White Box testing (as far as I understand) is more useful in a debugging mindset.

  • -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 Brown May 17 '14 at 21:31
  • 1
    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

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).


Neither. I try to write good tests using my Right BICEP, keeping in mind CORRECT boundary conditions no matter what order they come to mind. Those are both acronyms proposed in Pragmatic Unit Testing.

My goal is to focus on writing good tests, and not which colour to write first.

  • 'White' and 'black' aren't unit testing terms, so of course you aren't worrying about it. Unit tests are de facto white box. – Ethel Evans Dec 21 '10 at 19:15
  • @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. – Steven Evers Dec 21 '10 at 19:32

First do it white box testing.

Second go for Black box testing.

> Black Box Testing

I. The tester should check functional of the application, such Text box, Radio button, listbox, Command button,... etc.,,

II. The tester should check non functional of the application, such logo, Image, spelling,.. etc.,,

III. The tester should check entire flow of the application.

Note: To check Positive and Negative conditions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.