Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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
add comment

10 Answers 10

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.

share|improve this answer
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
add comment

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.

share|improve this answer
1  
Well said, best answer I read thus far. –  Chris Dec 20 '10 at 12:56
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
'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. –  Steve Evers Dec 21 '10 at 19:32
add comment

Black

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.

share|improve this answer
2  
Unless, of course, the black box tests missed testing a key piece of functionality or configuration :} –  Alan Dec 17 '10 at 19:15
2  
@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, if this would be true, TDD (which produces white box tests) would be useless. –  Doc Brown May 17 at 21:38
    
@DocBrown: TDD as espoused by Beck et al tests only the outcomes of the unit test scenarios, not every possible path, which is black-box testing –  Steven A. Lowe May 19 at 20:59
show 3 more comments

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
-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 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 at 10:54
add comment

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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