Definition “Black-box and white-box testing” The difference between black-box and white-box testing
White- and black-box tests are two methods that can be used to check components, code and runnability. Due to their differences, both test methods are suitable in practice for very different scenarios.
Black-box and glass or white-box tests are not mutually exclusive, but on the contrary can complement each other.
White box testing and black box testing are two different methods of software testing in which testers have different knowledge of the software to be tested. Accordingly, both methods have their own advantages and disadvantages – where exactly these are, it is best to clarify in a direct comparison.
White-box test – a brief definition
The white box test is also called the glass box test, the metaphor of a glass box also explains quite well what this test method is about. Test persons have knowledge of the code and the functions of a software, in some cases they can also look up live in the code.
White-box tests are very easy to carry out and are mainly used to detect errors in individual software components. Automation of the test procedure is also possible here without any problems. They are usually used to identify internal security gaps, to check specific input paths or to view statements, objects and functions separately.
Black box test – a brief definition
In the black box test, testers are groping in the dark, so to speak, they do not know how a software works, how it is implemented or what components it consists of. Instead, the test is based on the specifications, so all visible components are tested. Black-box tests are carried out, for example, by valid and invalid inputs, in which users examine the functioning of a system by expected and incorrect inputs and actions.
In practice, there are three different versions of a black box test:
- Functional Testing: the test of the functionality and running ability of a software.
- Non-functional testing: in this form of black box testing, systems are not tested for their running ability, but for scalability, operability and performance, i.e. the “soft” components.
- Regression Testing: this black box test tests a software that has already been tested by black box tests again after upgrades, patches or other interventions in the code. The aim is to determine the ability of new code parts to run in a proven working environment.
The main differences between black box and white box tests
When looking at the differences between the two test methods, it should always be noted that black and white box testing are not mutually exclusive. In many scenarios, internal white-box tests are a suitable precursor for externally organized black-box tests.
Mixing methods such as grey box testing can also be used, where there is a sketchy understanding of the code to ensure integration or penetration testing under black box scenarios while at the same time providing insight into the functionality of the software.
Internal/external
White-box testing is a method that can also be carried out internally and, due to its focus on individual components, can also be optimally automated. Internal testing can also be an advantage because the developers know the written code. If a white-box test is outsourced, at least programming knowledge of the language used is necessary.
Black box tests, on the other hand, do not require any programming knowledge and can (or should) therefore be carried out externally. Testers only need an understanding of the specifications of a software, but this requires more logistical effort for testing companies.
Targets
White-box tests primarily determine the quality of the code and check how robust and optimized it is with regard to individual components. Black-box tests, on the other hand, are better suited for looking at the functioning of a software as a whole.
Start time
A white-box test can begin as soon as a detailed design document and executable code for some components have been created. For black-box tests, the specifications and application scenarios must be defined, in addition, an executable software must be available.
Test person
In white-box tests, the programmers themselves typically test and analyze, after all, this eliminates the need for familiarization with the code. Black-box tests, on the other hand, are carried out by end-users or dedicated test subjects.
Minuses
White-box tests have the disadvantage that they consider the code and the functionality of a system isolated from the specifications. The test is therefore not particularly practical and does not check whether users can ultimately use the software as a whole as intended.
Efficiency and running ability are in the foreground
Software development always reaches its limits when fixing errors and even intensive testing cannot rule out any errors in the code or defects in the fulfillment of specifications. However, this is not an argument against intensive testing, but rather shows the need for even better testing procedures in order to eliminate as many problems as possible. White-box and black-box tests are part of test procedures that complement each other perfectly and should therefore also be used together.
As of 30.10.2020
It is a matter of course for us that we handle your personal data responsibly. If we collect personal data from you, we process it in compliance with the applicable data protection regulations. Detailed information can be found in our privacy policy.
Consent to the use of data for advertising purposes
I agree that Vogel IT-Medien GmbH, Max-Josef-Metzger-Straße 21, 86157 Augsburg, including all companies affiliated with it within the meaning of §§ 15 et seq. AktG (hereinafter: Vogel Communications Group) may use my e-mail address for sending editorial newsletters. Lists of the associated companies can be found here.
The newsletter content covers products and services of all the aforementioned companies, including, for example, trade journals and specialist books, events and trade fairs as well as event-related products and services, print and digital media offers and services such as further (editorial) newsletters, competitions, lead campaigns, market research in the online and offline area, subject-specific web portals and e-learning offers. If my personal telephone number has also been collected, it may be used for the submission of offers of the aforementioned products and services of the aforementioned companies and market research.
If I call up protected content on the Internet on portals of the Vogel Communications Group, including its affiliated companies within the meaning of §§ 15 et seq. AktG, I must register with further data for access to this content. In return for this royalty-free access to editorial content, my data may be used for the purposes mentioned here within the meaning of this consent.
Right of withdrawal
I am aware that I can revoke this consent at any time for the future. My revocation does not affect the legality of the processing carried out on the basis of my consent until the revocation. To explain my revocation, I can, as a possibility, do this under https://support.vogel.de use the available contact form. If I no longer wish to receive individual newsletters I have subscribed to, I can also click on the unsubscribe link included at the end of a newsletter. Further information on my right of revocation and its exercise as well as on the consequences of my revocation can be found in the privacy policy, section Editorial newsletters.
