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. |
|||||
|
BlackBlack-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. |
|||||||||||||
|
|
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. |
|||||||
|
|
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. |
|||
|
|
|
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. |
|||
|
|
|
If you want to have a good test cycle, you should have different people doing Both:
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 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. |
|||
|
|
|
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. |
||||
|
|