In the traditional interpretation, so to speak, there are two main definitions of the testing methods: open, transparent box (white-box testing) and closed box (black-box testing) types. Some interpreters literally translate these terms as black box test design technique/methodology and white-box test design methodology. When software testing service providers use the first method they aim to investigate the internal structure of the program and, vice verse, resorting to the second technique they examine the product’s functionality based on the specification.
So, as the name implies, an open box testing takes place when you see inside the box and in this case, you need to know the internal workings of the software code. When this occurs, the engineer examines the code written by the programmer, and makes its own amendments to it (e.g., “If the value of this variable goes beyond the limits set forth in the user’s manual, this cycle will be infinite,” or “When you connect to the database using this method and after its execution it is impossible to break this connection, it will happen that after some subsequent invocation of the method, connection to the database will not be established “). As you can guess, a person capable of conducting an analysis of the kind must be both an expert in the testing field (he must be able to predict what the user can “blurt out”) and a good programmer. As a rule, the job responsibilities of white-box QA specialist include writing the so-called unit tests. Regression testing services appear to be indispensable to make sure that software changes have no unintended side effects.
Testing of closed source code is the most common task and, again, as the name implies it does not suggest the possibility of accessing the source code of the software.
Fortunately or unfortunately, nothing is completely white or completely black in this world. So there is a concept of semi-transparent testing in QA field (gray-box testing). It takes place when the tester can only partially see inside the box. By the way, automation of testing processes is just included in this methodology. Semi-open code means that the tester is familiar with the architecture (e.g., with the standard scheme of industrial (enterprise level software) applications: Oracle – WebLogic – JavaApplet) software; he can go to the server and view the execution log; he knows the structure of the data model for the software under consideration, and if anything crops up he will be able to write SQL-query to confirm the results issued by the software product (SP). That is, he does not seem to be an expert in computer programming (as Whitebox QA), but at the same time, he is already not only a tester. In fact, all the three testing activities should be supervised by experts exactly in the field.
Multi-platform testing services are available to know if the products are interoperable or portable across different platforms.