What Is Black Box And White Box Testing Strategy

What is a White Box Testing Strategy? White box testing strategy deals with the internal logic and structure of the code. White box testing is also called as glass, structural, open box or clear box testing. The tests written based on the white box testing strategy incorporate coverage of the code written, branches, paths, statements and internal logic of the code etc. In order to implement white box testing, the tester has to deal with the code and hence is needed to possess knowledge of coding and logic i.e. internal working of the code. White box test also needs the tester to look into the code and find out which unit/statement/chunk of the code is malfunctioning. Advantages of White box testing are: i) As the knowledge of internal coding structure is prerequisite, it becomes very easy to find out which type of input/data can help in testing the application effectively. ii) The other advantage of white box testing is that it helps in optimizing the code iii) It helps in removing the extra lines of code, which can bring in hidden defects. Disadvantages of white box testing are: i) As knowledge of code and internal structure is a prerequisite, a skilled tester is needed to carry out this type of testing, which increases the cost. ii) And it is nearly impossible to look into every bit of code to find out hidden errors, which may create problems, resulting in failure of the application. Types of testing under White/Glass Box Testing Strategy: Unit Testing: The developer carries out unit testing in order to check if the particular module or unit of code is working fine. The Unit Testing comes at the very basic level as it is carried out as and when the unit of the code is developed or a particular functionality is built. Static and dynamic Analysis: Static analysis involves going through the code in order to find out any possible defect in the code. Dynamic analysis involves executing the code and analyzing the output. Statement Coverage: In this type of testing the code is executed in such a manner that every statement of the application is executed at least once. It helps in assuring that all the statements execute without any side effect. Branch Coverage: No software application can be written in a continuous mode of coding, at some point we need to branch out the code in order to perform a particular functionality. Branch coverage testing helps in

1|Page

validating of all the branches in the code and making sure that no branching leads to abnormal behavior of the application. Security Testing: Security Testing is carried out in order to find out how well the system can protect itself from unauthorized access, hacking – cracking, any code damage etc. which deals with the code of application. This type of testing needs sophisticated testing techniques. Mutation Testing: A kind of testing in which, the application is tested for the code that was modified after fixing a particular bug/defect. It also helps in finding out which code and which strategy of coding can help in developing the functionality effectively. Besides all the testing types given above, there are some more types which fall under both Black box and White box testing strategies such as: Functional testing (which deals with the code in order to check its functional performance), Incremental integration testing (which deals with the testing of newly added code in the application), Performance and Load testing (which helps in finding out how the particular code manages resources and give performance etc.) etc.

What is white box testing? White box testing traditionally refers to the use of program source code as a test basis, that is, as the basis for designing tests and test cases. (IEEE standards define a test as "a set of one or more test cases.") A looser definition says that "white box testing is based on internal structures of the software", but it is very unclear what kinds of "internal structure" are covered by this. Some authorities, for example, include user-facing menus and even business processes. The term "gray box testing" is now in widespread use for internal software structures that are not actually source code - for example, class hierarchies or module call trees. In the following discussion, "white box testing" is held to be synonymous with "code-based testing." Those two terms are opposed to "requirements-based" or "specification-based" testing, also known as black box testing. The implication there is that you can't see the inner workings of a black-painted box; and in fact, you don't need to see the inner workings to test whether a given set of inputs results in the required or specified set of outputs. But if you do need to test the inner workings, painting the box white would leave them just as invisible as when the box was black, so the terms "clear box testing" and "glass box testing" are also used. (The word "analysis" is sometimes used in place of "testing.") White-box testing usually involves tracing possible execution paths through the code and working out what input values would force the execution of those paths. Quite simple techniques exist by which the tester (usually the developer who wrote the code) can work out the smallest number of paths necessary to test, or "cover," all the code. Some types of static analysis tool will do the same job, more quickly and more reliably. White box testing, on its own, cannot identify problems caused by mismatches between the actual requirements or specification and the code as implemented but it can help identify some types of design weaknesses in the code. Examples include control flow problems (e.g., closed or infinite loops or unreachable code), and data flow problems (e.g., trying to use a variable which has no defined value). Static code analysis (by a tool) may also find these sorts of problems, but doesn't help the

2|Page

tester/developer understand the code to the same degree that personally designing white-box test cases does. White box testing is usually associated with component testing (i.e., unit testing), and with the concept that, at minimum, 100% of the component's code statements should be tested before the component is released for use ("100% code coverage"). But it may be dangerous to design white box test cases simply to achieve such a standard. This is not only because it will miss disconnects between code and specifications, but because the test cases are often artificial and unrepresentative of how the component will actually be used. The test cases may even be impossible to execute (corresponding to "unachievable" or "infeasible" paths. A tool will avoid generating these). A better approach may be to design enough test cases to cover all requirements specified for the component (black box testing), then use a code coverage monitor to record how much of the code is actually covered (executed) when the test cases are run. Often, the code will fall into two parts: code statements that correspond directly to the requirements and get covered by the black box test cases; and code statements that deal with aspects of the target execution environment, which may not be explicitly specified but which the developer is expected to provide. This second type of code often provides error handling for exceptions thrown by hardware or software conditions (e.g., by a database management system), and often goes untested - which may cause severe problems when such an exception occurs in live use. The developer would use white box techniques to work out how to drive the testing of those statements not covered by the black box test cases.

What is a Black Box Testing Strategy? Black Box Testing is not a type of testing; it instead is a testing strategy, which does not need any knowledge of internal design or code etc. As the name "black box" suggests, no knowledge of internal logic or code structure is required. The types of testing under this strategy are totally based/focused on the testing for requirements and functionality of the work product/software application. Black box testing is sometimes also called as "Opaque Testing", 3|Page

"Functional/Behavioral Testing" and "Closed Box Testing". The base of the Black box testing strategy lies in the selection of appropriate data as per functionality and testing it against the functional specifications in order to check for normal and abnormal behavior of the system. Now a days, it is becoming common to route the Testing work to a third party as the developer of the system knows too much of the internal logic and coding of the system, which makes it unfit to test the application by the developer. In order to implement Black Box Testing Strategy, the tester is needed to be thorough with the requirement specifications of the system and as a user, should know, how the system should behave in response to the particular action. Various testing types that fall under the Black Box Testing strategy are: functional testing, stress testing, recovery testing, volume testing, User Acceptance Testing (also known as UAT), system testing, Sanity or Smoke testing, load testing, Usability testing, Exploratory testing, ad-hoc testing, alpha testing, beta testing etc. These testing types are again divided in two groups: a) Testing in which user plays a role of tester and b) User is not required. Testing method where user is not required: Functional Testing: In this type of testing, the software is tested for the functional requirements. The tests are written in order to check if the application behaves as expected. Stress Testing: The application is tested against heavy load such as complex numerical values, large number of inputs, large number of queries etc. which checks for the stress/load the applications can withstand. Load Testing: The application is tested against heavy loads or inputs such as testing of web sites in order to find out at what point the web-site/application fails or at what point its performance degrades. Ad-hoc Testing: This type of testing is done without any formal Test Plan or Test Case creation. Ad-hoc testing helps in deciding the scope and duration of the various other testing and it also helps testers in learning the application prior starting with any other testing. Exploratory Testing: This testing is similar to the ad-hoc testing and is done in order to learn/explore the application. Usability Testing: 4|Page

This testing is also called as ‘Testing for User-Friendliness’. This testing is done if User Interface of the application stands an important consideration and needs to be specific for the specific type of user. Smoke Testing: This type of testing is also called sanity testing and is done in order to check if the application is ready for further major testing and is working properly without failing up to least expected level. Recovery Testing: Recovery testing is basically done in order to check how fast and better the application can recover against any type of crash or hardware failure etc. Type or extent of recovery is specified in the requirement specifications. Volume Testing: Volume testing is done against the efficiency of the application. Huge amount of data is processed through the application (which is being tested) in order to check the extreme limitations of the system. Testing where user plays a role/user is required: User Acceptance Testing: In this type of testing, the software is handed over to the user in order to find out if the software meets the user expectations and works as it is expected to. Alpha Testing: In this type of testing, the users are invited at the development center where they use the application and the developers note every particular input or action carried out by the user. Any type of abnormal behavior of the system is noted and rectified by the developers. Beta Testing: In this type of testing, the software is distributed as a beta version to the users and users test the application at their sites. As the users explore the software, in case if any exception/defect occurs that is reported to the developers.

What is a Black Box Testing? A black box is any device whose workings are not understood by or accessible to its user. According to Edward Tenner, writing in The Washington Post, the first black box was a gun sight carried on World War II Flying Fortresses, with hidden components that corrected for environmental variables, such as wind speed. The crew probably didn't know how the device worked, but they knew it might be crucial to their survival. Nowadays, there are two types of 5|Page

black box carried on aircraft, which may be combined into a single device: a flight data recorder (FDR), which logs information such as speed and altitude, and a cockpit voice recorder (CVR), which logs all voice communication in the cockpit. These black boxes also carry beacons to help find the aircraft in a rescue situation. A sampling of other black boxes: • In telecommunications, a black box is a resistor connected to a phone line that makes it impossible for the telephone company's equipment to detect when a call has been answered. • In data mining, a black box is an algorithm or a technology that doesn't provide an explanation of how it works. • In software development, a black box is a testing method in which the tester has no knowledge of the inner workings of the program being tested. The tester might know what is input and what the expected outcome is, but not how the results are achieved. A black box component is a compiled program that is protected from alteration by ensuring that a programmer can only access it through an exposed interface. • In film-making, a black box is a dedicated hardware device: equipment that is specifically used for a particular function. • In the theatre and television, a black box is an unfurnished studio. • In the financial world, a black box is a computerized trading system that does not make its rules easily available. Perhaps because the metaphor is broadly applicable, black box is sometimes used to refer to anything that works without its inner workings being understood or accessible for understanding. Learn more about Software testing models and approaches (Context-driven, Factory, Analytic, Quality, IV&V) Why automated software testing fails and pitfalls to avoid: Chapter 4 from published title "Why Automated Software Testing Fails and Pitfalls to Avoid" offers new takes on automated R&D, software development considerations and much more. Agile software development tutorial: Agile testing: In this section of our agile tutorial, learn how to be a successful software tester in an agile environment, from tips on test development to exploratory testing techniques. Software testing fundamentals: Testing basics: Software testing experts weigh in on creating test plans, writing test cases, choosing test models and other basic building blocks of software testing. Rich Internet applications security testing checklist: Fix common RIA and Web 2.0 application problems caused by Ajax, Flash and other technologies with these tips. Seven steps for a quality change and configuration management program: This tip outlines several ways to ensure you have a topnotch change and configuration management (CCM) division on your project team which is vital in protecting software code. 6|Page

7|Page