Black box testing

This testing involves running the program under known conditions with defined inputs, and documented outcomes that can be compared to predefined expectations. Functional testing is sometimes called black box testing. 

Black box testing is also known as functional testing, benchmark testing and, in the pharmaceutical community, as an operational qualification (OQ). It tests the functionality and correctness of a computer system by running the integrated software, and is performed for one of two reasons defect detection, and/or reliability estimation. It should cover all functions of the application software that the end-user will use, and will verily the completeness and accuracy of system requirements used to define the test cases. 

A black box test involves providing an input to the system and then examining the output. The structural elements of the application software are not examined during the execution of a black box test these elements are examined during a white box test. An OQ is a black box (result oriented) system test, designed to determine the degree of accuracy with which the system responds to a stimulus. The following sections describe some test cases that an OQ may contain. 

All computer systems performing regulated operations must be validated. To support computer systems validation, standard instmments, microcontrollers, and smart instrumentation are functionally tested (black box test) and the installed versions recorded. 

The operational qualification for standard instruments, microcontrollers, and smart instrumentation consists of a black box test. This type of test is based on the user s firm application requirement and challenges a program s external influences. It views the software as a black box concerned with program inputs and its corresponding outputs. The black box testing must consider not only the expected (normal) inputs, but also unexpected inputs. Black box testing is discussed in Chapter 9. 

The operational qualification for standard software packages consists of a black box test. This type of test is based on the user s firm application requirements specification deliverable and challenges the packages external influences. 

A common problem with COTS products is that access to product development documentation may not be available. The supplier may refuse to share its proprietary information, or it may be unavailable for some other reason. In such circumstances pharmaceutical and healthcare companies are expected by the regulatory authorities to compensate with additional black box testing to establish with sufficient confidence that the COTS products meet user needs. (Black box testing is... 

System Testing is conducted by the supplier to verify that the computer system s intended and defined functionality has been achieved. Such Functional Testing is often referred to as Black Box Testing because it does not focus on the internal workings of a system (components and subsystems) rather, the focus is on the complete system as a single entity (see Figure 10.4). 

Bespoke Element Developments Writing extra software to complement the standardized application. These modihcations may impinge on standard software stams, but cau be compensated by overall functional (black box) testing. Bespoke code must itself be fully validated, including strucmral (white box) testing. 

To address concerns that source codes for OTS software may not be available the FDA will allow black box testing as a validation method whenever source codes and design specihcations carmot be obtained from suppliers. Alternatively, a Supplier Audit may be used to document that the supplier employed acceptable software programming practices. 

Functional Testing GAMP Forum (1996) Also known as Black Box testing, since source code is not needed. This involves inputting normal information and abnormal test cases and then, evaluating outputs against those expected. Can apply to computer system or to a total system. [Adapted.]... 

It is suggested that White and Black box test cases design strategies be used to sample the data (input domain), including Equivalent Partitioning, Boundary Analysis and Error Guessing, Cause-Effect Graphing, and Structural Tableau. 

Modules, including interfaces, should generally be tested against the System Design Specification. Testing may include black box tests, white box tests and a Source Code Review. 

The overall system should generally be tested against the URS/functional description. Black box tests are most appropriate here. 

System Software POL Interpreter Error - White Box tests and Black Box tests in Developing Phase - Validation... 

Black-box testing - S/W requirements-based test cases. 

Black-box tests of the dynamic behavior under real functional conditions to reveal failures to meet the SRECS safety functional specification. 

Robustness testing is a specific form of black-box testing that attempts to characterize the behavior of a system in the presence of erroneous or unexpected input conditions [7]. The tool instrumented in the testing framework implements the technique proposed in [13]. The approach consists of a set of robustness tests that is applied during execution in order to disclose both programming and design problems. 

For SILl/2 Rl—limited objective acceptance criteria (e.g., black box test, field trial)... 

---