Divide and Conquer in Software Testing

This is all about testing.

To break down the testing tasks, the following “what,” “when,” “how,” and “who” questions should be answered.

What Should be tested? During the test-planning phase, what to test and what not to test will have been determined as part of the scope of testing.

When should test procedure be developed? Test procedure be developed as soon as requirements are available. (unfortunately we don't have that Test Procedures). Once it has been determined what to test, the sequence of tests must be established. What needs to be tested first? The test planner should get to know the testing priorities, and should become familiar with the build and release schedule. Procedures for testing the high-priority items should be developed first.

How should test procedures be designed? No single testing solution can effectively cover all parts of a system. Test procedures for the different parts of the system must be designed in the manner most appropriate for effectively testing each of those specific parts.

In order to design the appropriate and most effective tests, it is necessary to consider the parts that make up the system and how they are integrated.

Who should develop the tests? Once it has been determined what must be tested, when it is to be tested, and how the test is to be accomplished, it will be easier to decide to whom the various testing tasks should be assigned.

Since user-interface, or black-box, testing does not exhibit all defects, gray-box testing must also be applied.

Keep in mind that black-box and gray-box testing combined are still not sufficient to procedure a quality product. Testing processes, procedures, inspections, and walk-through s, along with unit and integration testing, are all important parts of effective testing. Black-box and gray-box testing alone cannot identify all of the defects in a software program.