| Black Box Testing | White Box Testing |
| The black box testing procedure promotes a rigorous and comprehensive approach to application analysis. The goal is quality assurance for the end user. The process begins with the testing team understanding the requirement statement of the application. This step generally requires the presence of a well-documented software requirement specification. Testing methodologies such as equivalence partitioning and boundary value analysis are used to determine sets of valid inputs and their predicted outputs. This information is then used to build test cases, which are then run to check whether they are successful or not. The actual outcomes are compared against the intended outcomes, and failed test cases are classified as bugs or defects. These bugs are reported to the development team, who then work on fixing them. Once the developers update the application, the testing team retests the previously reported problem areas and checks if they have been fixed. | The white box testing process is much more ‘surgical’ than black box testing and far more effective on smaller targets. The goal is to assess all the possible cases and scenarios for the target, which is often a ‘too-critical-to-fail’ application, component, or functionality. The first step is identifying the target: the component, feature, or application to be tested. By choosing a narrow target, white box testers can be thorough and ensure flawless functionality. This is usually achieved by picking the smallest possible logical module, working on it and then moving on to the next one. Of course, one can also execute white box testing on larger systems; however, this is often a resource-intensive process and should only be done if the need is greater than the effort. The next step is creating a flow graph by plotting all possible scenarios. This helps determine the scope of the testing exercise and write relevant test cases. Scenarios must account for user journeys, program specifications, use cases, technical specifications, and pseudocode. Once the flow graph is prepared, all the paths the journey might take must be mapped for testing and framed as test cases. Finally comes the execution phase, where the testing is completed, and any issues are recorded for fixing. |
Comments
Post a Comment