| 1: | Why does knowing how the software works influence how and what you should test? |
| A1: | If you test only with a black-box view of the software, you won't know if your test cases adequately cover all the parts of the software nor if some of the cases are redundant. An experienced black-box tester can design a fairly efficient suite of tests for a program but he can't know how good that suite is without some white-box knowledge. |
| 2: | What's the difference between dynamic white-box testing and debugging? |
| A2: | Both processes overlap, but the goal of dynamic white-box testing is to find bugs and the goal of debugging is to fix them. The overlap occurs in the area of isolating exactly where and why the bug occurs. |
| 3: | What are two reasons that testing in a big-bang software development model is nearly impossible? How can these be addressed? |
| A3: | With the software delivered to you in one big piece, it's difficult, if not impossible, to figure out why a bug occursthe needle-in-a-haystack problem. The second reason is that there are so many bugs, some hide others. You'll grab one and shout "gotcha" only to discover that the software is still failing. Methodically integrating and testing the modules as they are built allows you to find and fix bugs before they start to become hidden or pile on top of each other. |
| 4: | True or False: If your product development is in a hurry, you can skip module testing and proceed directly to integration testing. |
| A4: | True. You can, but you shouldn't. Doing so will cause you to miss bugs that could have been found earlier. Skipping or postponing testing generally makes your project take longer and cost more to complete. |
| 5: | What's the difference between a test stub and a test driver? |
| A5: | A test stub is used in top-down testing. It stubs out, or substitutes itself, for a low-level module. It looks and acts to the higher-level code being tested just like the original low-level module. A test driver is the opposite of a stub and is used in bottom-up testing. It's test code that replaces higher-level software to more efficiently exercise a low-level module. |
| 6: | True or False: Always design your black-box test cases first. |
| A6: | True. Design your test cases based on what you believe the software is supposed to do. Then use white-box techniques to check them and make them most efficient. |
| 7: | Of the three code coverage measures described, which one is the best? Why? |
| A7: | Condition coverage is the best because it also incorporates branch coverage and statement coverage. It tests that the conditions within decision logic, such as if-then statements, are verified, as well as branches from those statements and the lines of code. |
| 8: | What's the biggest problem of white-box testing, either static or dynamic? |
| A8: | You can easily become biased. You might look at the code and say, "Oh, I see, I don't need to test that case, the code handles it properly." In reality, you were blinded by the light and eliminated necessary test cases. Be careful! |
