Validate and test requirements that must comply with the software. Validate that the requirements were implemented correctly verify the interaction of components. Verify proper integration of components. Verify that all requirements have been implemented correctly. Identify and secure that defects found have been corrected before releasing the software to the customer. Design tests that systematically take to light different kinds of errors, doing so with the least amount of time and effort. (2) 1.3 Classification and application of testing when be begins to work in a particular software, it is necessary to make them different forms of evidence, to achieve good quality in it and thus to achieve the least possible amount of errors.

This is why tests are classified into two large groups, that all application can be tested under the following schemes: 1) knowing the function of the product (program), demonstrate that function goes well. This case is about interfaces and it is called black box testing. (2) Demonstrate that the internal operation of the module conforms to specified and internal components to walk well, (this test is) It develops based on logical module paths, is called white box testing). The latter is the test that best reveals the difficulties. White box testing: enable you to examine the internal structure of the program. Test cases are designed to examine the logic of the program. It is a method of design of test cases using the procedural design control structure to derive test cases to ensure that: 1) running at less than once all the ways independent of each module.

(2) That all logical decisions in its true and false branches are tested. (3) Execute all loops or cycles with the limits you have set them. (4) Run the internal data structures to ensure its validity. Black box techniques or methods: are complementary to the white box. But in practice, only the black box test is usually done.