The main disadvantage of black-box testing is that the tester does not know how the system was implemented and but knows only some part of its internal structure and the inputs. He is also aware of expected outputs but is unaware of how the program will arrive at them. Some existing paths in the program (which are not specified either in the product’s requirements or in the other project documentation) can never be checked. The number of such paths can be reduced by analyzing the internal workings of the program.
If the program uses a database for working with data, we can analyze the types of fields which contain program variables. And then we can proceed to analysis of the resource limitations imposed by the database.
For example, if the user’s input name is written in a string field with length not less than 128 characters, we must:
1) try to choose a surname longer than 128 characters – there will be a rather serious bug, if such surnames exist – a person with such a name cannot use our system;
2) regardless of whether such names exist or not, try typing a string longer than 128 characters – the program should not crash (there should be a clear error message).
Other external systems
If the program can be integrated with other external systems, in addition to the database, you can also analyze constraints of such systems. For example, if we are testing an IMAP email client, we need to make sure that it correctly handles long paths to folders on the server (most often, the maximum length for a path is 255 characters).
If we have access to the program code, we can:
- a) obtain special test cases that are not present in the requirements specification document and which need to be tested or, on the contrary
- b) understand that it does not make sense to test some things.
Methods for selecting test cases for white-box testing
White-box testing is not functional, but structural technique used to validate the structure of the program code to understand which line of it is executed and which isn’t. A white box tester should therefore have programming skills. The main disadvantage of this testing is that the tester can never know that some functionality is not implemented, because you can test only the features that are currently there.
There are two methods for selecting test cases:
- Control-flow testing.
- Data-flow testing.
These methods are described in detail in A Practitioner’s Guide to Software Test Design (Lee Copeland). The description is beyond the scope of this lecture, as they are not functional testing techniques. However, there is a list of software testing companies to help you find the best testing providers in no time.