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