Black box vs White box Testing

Question

Which type of testing would you say should be the emphasis (for testers/QAs), and why?

A quick set of definitions from wikipedia:

Black box testing

• takes an external perspective of the test object to derive test cases. These tests can be functional or non-functional, though usually functional. The test designer selects valid and invalid input and determines the correct output. There is no knowledge of the test object's internal structure.

White box testing

• uses an internal perspective of the system to design test cases based on internal structure. It requires programming skills to identify all paths through the software. The tester chooses test case inputs to exercise paths through the code and determines the appropriate outputs. In electrical hardware testing, every node in a circuit may be probed and measured; an example is in-circuit testing (ICT).

edit: just to clarify a bit more, I realize that both are important, but usually they are separate between dev and QA.

Is internal knowledge important for the tester/QA? I've heard arguments that testing with this knowledge in mind enables them to better test for problems, but I've also heard arguments that this knowledge can distract from functional needs and promote "testing to to the code" rather than to the intended solution.

Answer 1

• *Black box testing: Is the test at system level to check the functionality of the system, to ensure that the system performs all the functions that it was designed for, Its mainly to uncover defects found at the user point. Its better to hire a professional tester to black box your system, 'coz the developer usually tests with a perspective that the codes he had written is good and meets the functional requirements of the clients so he could miss out a lot of things (I don't mean to offend anybody)
• Whitebox is the first test that is done in the SDLC.This is to uncover bugs like runtime errors and compilation errrors It can be done either by testers or by Developer himself, But I think its always better that the person who wrote the code tests it.He understands them more than another person.*

Answer 2

QA should focus on Black box testing. The main goal of QA is to test what the system does (do features meet requirements ?), not how it does it.

Anyway it should be hard for QA to do white box testing as most of QA guys aren't tech guys, so they usually test features through the UI (like users).

A step further, I think developpers too should focus on Black box testing. I disagree with this widespread association between Unit testing and White box testing but it may be just a question a vocabulary/scale. At the scale of a Unit test, the System Under Test is a class/method which has contract (through its signature) and the important point is to test what it does, not how. Moreover White box testing implies you know how the method will fill its contract, that seems incompatile with TDD to me.

IMHO if your SUT is so complex that you need to do white box testing, it's usually time for refactoring.

Answer 3

It's a bit of an open door, but in the end both are about equally important.

What's worse?

1. software that does what it needs to do, but internally has problems?

2. software that is supposed to work if you look at the sources, but doesn't?

My answer: Neither is totally acceptable, but software cannot be proven to be 100% bugfree. So you're going to have to make some trade-offs. Option two is more directly noticable to clients, so you're going to get problems with that sooner. On the long run, option one is going to be problematic.

Answer 4

*Black-Box testing: If the source code is not available then test data is based on the function of the software without regard to how it was implemented. -strong textExamples of black-box testing are: boundary value testing and equivalence partitioning.

*White-Box testing: If the source code of the system under test is available then the test data is based on the structure of this source code. -Examples of white-box testing are: path testing and data flow testing.

Answer 5

• Black box testing should be the emphasis for testers/QA.
• White box testing should be the emphasis for developers (i.e. unit tests).
• The other folks who answered this question seemed to have interpreted the question as Which is more important, white box testing or black box testing. I, too, believe that they are both important but you might want to check out this IEEE article which claims that white box testing is more important.

Answer 6

Black Box

1 Focuses on the functionality of the system Focuses on the structure (Program) of the system

2 Techniques used are :

· Equivalence partitioning

· Boundary-value analysis

· Error guessing

· Race conditions

· Cause-effect graphing

· Syntax testing

· State transition testing

· Graph matrix

Tester can be non technical

Helps to identify the vagueness and contradiction in functional specifications

White Box

Techniques used are:

· Basis Path Testing

· Flow Graph Notation

· Control Structure Testing

1. Condition Testing

2. Data Flow testing

· Loop Testing

1. Simple Loops

2. Nested Loops

3. Concatenated Loops

4. Unstructured Loops

   Tester should be technical

   Helps to identify the logical and coding issues.