Black Box Testing Probably this is what most of us practice and is used most widely. This is also type of testing which is very close to customer experience. In this type of testing system is treated as close system and test engineer do not assume any thing about how system was created. As a test engineer if you are performing black box test cases, one thing that you need to make sure is that you do not make any assumptions about the system based on your knowledge. Assumption created in our mind because of the system knowledge could harm testing effort and increase the chances of missing critical test cases. Only input for test engineer in this type of testing is requirement document and functionality of system which you get by working with the system. Purpose of black box testing is to Make sure that system is working in accordance with the system requirement. Make sure that system is meeting user expectation. In order to make sure that purpose of black box testing is met, various techniques can be used for data selection like Boundary value analyses Equivalence partitioning Activities within every testing types can be divided into verification and validation. Within black box testing following activities will need verification techniques Review of requirement and functional specification. Review of Test plan and test cases. Review of test data And test case execution will fall under validation space. Boundary Value Analysis Testing Boundary value analysis is the technique of making sure that behavior of system is predictable for the input and output boundary conditions. Reason why boundary conditions are very important for testing is because defects could be introduced at the boundaries very easily. For example, if you were to write code to simulate following condition – " Input should be greater than equal to 10 and less than 50" Probably you will write something like if (input >=10 AND input <50) then do some else do some thing else. So, according to this input values from 10 to 49 are valid, but if you make mistake in specifying the conditions, following things can happen input >10 AND input <50 -------> Input value 10 in invalid now. input <=10 AND input <50 -------> Input value 9 is valid now. input >=10 AND input <=50 -----> Input value 50 is valid now input >=10 AND input >50 -----> Input value 49 is invalid now Because it is very easy to introduce defects at boundaries, boundary values are important. So for the above example, at the minimum we should have following test cases for boundaries 9, 10, 11 and 48, 49, 50 lower_boundary - 1, lower_boundary, lower_boundary + 1 and upper_boundary - 1, upper_boundary, upper_boundary + 1 Do you think boundary value analyses can be used for other boundaries as well? Have you ever used boundary value analyses with some variation to suite your project need? It will be great if you can share your experience of boundary value analyses with us, if approved it will be published under case studies section. Equivalence Partitioning Equivalence partitioning is a software testing technique to minimize number of permutation and combination of input data. In equivalence partitioning, data is selected in such a way that it gives as many different out put as possible with the minimal set of data. If software behaves in an identical way for a set of value, then the set is termed as equivalence class or a partition. It can be assumed safely that functionality of the software will be same for any data value from the equivalence class or partition. In equivalence partitioning, input data is analyzed and divided into equivalence classes which produces different output. Now, data from these classes can be representative of all the input values that your software expect. For equivalence classes, it can be assumed that software will behave in exactly same way for any data value from the same partition. So essentially, there are two steps that you need to follow if you want to use equivalence partitioning in your projects - Identifying equivalence classes or partition Picking one value from each partition for the complete coverage. Main advantage of using this technique is that testing efforts are minimized and at the same time coverage is also ensured. Using this technique, redundancy of test cases is removed by eliminating data which does not produce different output. For example, consider a very simple function for awarding grades to the students. This program follow these guideline to award grades Marks 00 - 39 ------------ Grade D Marks 40 - 59 ------------ Grade C Marks 60 - 70 ------------ Grade B Marks 71 - 100 ------------ Grade A Based on the equivalence partitioning techniques, partitions for this program could be as follows Marks between 0 to 39 - Valid Input Marks between 40 to 59 - Valid Input Marks between 60 to 70 - Valid Input Marks between 71 to 100 - Valid Input Marks less than 0 - Invalid Input Marks more than 100 - Invalid Input Non numeric input - Invalid Input From the example above, it is clear that from infinite possible test cases (Any value between 0 to 100, Infinite values for >100 , < 0 and non numeric) data can be divided into seven distinct classes. Now even if you take only one data value from these partitions, your coverage will be good. Most important part in equivalence partitioning is to identify equivalence classes. Identifying equivalence classes needs close examination of the possible input values. Also, you can not rely on any one technique to ensure your testing is complete. You still need to apply other techniques to find defects. If you have used Equivalence Partitioning in some interesting way, why not share with all? Decision table Decision tables are a precise yet compact way to model complicated logic. Decision tables, like if-then-else and switch-case statements, associate conditions with actions to perform. But, unlike the control structures found in traditional programming languages, decision tables can associate many independent conditions with several actions in an elegant way. Structure Decision tables are typically divided into four quadrants, as shown below. The four quadrants Conditions Condition alternatives Actions Action entries Each decision corresponds to a variable, relation or predicate whose possible values are listed among the condition alternatives. Each action is a procedure or operation to perform, and the entries specify whether (or in what order) the action is to be performed for the set of condition alternatives the entry corresponds to. Many decision tables include in their condition alternatives the don't care symbol, a hyphen. Using don't cares can simplify decision tables, especially when a given condition has little influence on the actions to be performed. In some cases, entire conditions thought to be important initially are found to be irrelevant when none of the conditions influence which actions are performed. Aside from the basic four quadrant structure, decision tables vary widely in the way the condition alternatives and action entries are represented. Some decision tables use simple true/false values to represent the alternatives to a condition (akin to if-then-else), other tables may use numbered alternatives (akin to switch-case), and some tables even use fuzzy logic or probabilistic representations for condition alternatives. In a similar way, action entries can simply represent whether an action is to be performed (check the actions to perform), or in more advanced decision tables, the sequencing of actions to perform (number the actions to perform). Example The limited-entry decision table is the simplest to describe. The condition alternatives are simple boolean values, and the action entries are check-marks, representing which of the actions in a given column are to be performed. A technical support company writes a decision table to diagnose printer problems based upon symptoms described to them over the phone from their clients. Printer troubleshooter Rules Printer does not print Y Y Y Y N N N N Conditions A red light is flashing Y Y N N Y Y N N Printer is unrecognized Y N Y N Y N Y N Check the power cable X Check the printer-computer cable X X Actions Ensure printer software is installed X X X X Check/replace ink X X X X Check for paper jam X X Of course, this is just a simple example (and it does not necessarily correspond to the reality of printer troubleshooting), but even so, it demonstrates how decision tables can scale to several conditions with many possibilities. Software engineering benefits Decision tables make it easy to observe that all possible conditions are accounted for. In the example above, every possible combination of the three conditions is given. In decision tables, when conditions are omitted, it is obvious even at a glance that logic is missing. Compare this to traditional control structures, where it is not easy to notice gaps in program logic with a mere glance --- sometimes it is difficult to follow which conditions correspond to which actions! Just as decision tables make it easy to audit control logic, decision tables demand that a programmer think of all possible conditions. With traditional control structures, it is easy to forget about corner cases, especially when the else statement is optional. Since logic is so important to programming, decision tables are an excellent tool for designing control logic. In one incredible anecdote, after a failed 6 man-year attempt to describe program logic for a file maintenance system using flow charts, four people solved the problem using decision tables in just sixteen man-weeks .