Testing software documentation

The standard requires the supplier to establish and maintain documented procedures to control, calibrate, and maintain inspection, measuring, and test equipment including test software. 

What documented procedures have you established to control, validate, and maintain test software ... 

Document the methods you employ to denote inspection and test status for hardware, software, documents, and services. 

While the ISO 9001 requirement applies only to quality records, ISO/TS 16949 extends retention times for many other documents because you cannot demonstrate you have or had operations under control without specifications, plans, procedures, etc. You may also need to retain tools, jigs, fixtures, test software - in fact anything that is needed to repair or reproduce equipment in order to honor your long-term commitments. 

Software producers must fulfill the requirements for development, testing, and documentation. When the user is confident that these requirements have been met, and the system functions adequately to fulfill his or her needs, the user must perform validation prior to placing the software in service. An analytical laboratory is an example of an end-user that conducts testing prior to software/computer system installation. 

One practical example of the consequences of change control is that in the regime of system/instrument change control, hardware, software and operational aspects such as routine operation, maintenance and data integrity are locked down in fixed configurations. Any modification that has not been anticipated in the initial qualification requires testing and documentation. 

Only upon the successful completion of the integration testing and documentation review should product release be authorized. Once an application software program is released, it should be placed under formal configuration/ version control, and any revisions must follow the requirements of a change control procedure. 

The following documents supplied by the manufacturer can be used as part of this qualification description and instruction manual, installation drawings and instructions, test and take-over certificates and software documentation. It is recommended to list and specify all necessary documents and their format in the purchase order, as this reduces time and effort for both the buyer and the seller. 

All documents, hardware units, and software programs must be uniquely identified. It is not necessary to violate warranty seals in order to uniquely identify subcomponents. However, in situations where hardware units and software programs do not have a unique identification, physical labels and software header information can be added retrospectively. Unique identification should include the model number for hardware and the version number for software (e.g., MS Windows 2000 Professional Service Pack 2). Current approved versions of source code must correspond to current approved versions of software documents, object code, and test suites. All source code should have associated documentation. 

Quality control activities (e.g., software reviews, testing, and document reviews)... 

Software changes are carried out on a separate development system and are subject to the normal validation testing and documentation updates to the IPC application. Changes to hardware are assessed and tested for compatibility with the enviromnent and the system specification is updated to reflect the current installation. 

Abstract Installation and operational qualification are important steps in the overall validation and qualification process for software and computer systems. This article guides users of such systems step by step through the installation and operational qualification procedures. It provides guidelines on what should be tested and documented during installation prior to... 

Preferably, tests and documentation of results should be done automatically, always using the same set of test files. In this way users are encouraged to perform the tests more frequently, and user-specific errors are eliminated. In some cases, vendors provide test files and automated test routines for verification of a computer system s performance in the user s laboratory. Needless to say, the correct functioning of this software should also be verified. This can easily be done by changing the method or data file and rerunning the test. The report should indicate an error. If such automated verification software is not available, the execution of the tests and verification of actual results with prerecorded results can be done manually. 

FIGURE 8.1 The V-Model covers the entire process for software development from the business requirements to the implementation of the software in its intended operational environment. The process starts with a statement of work that defines the effort reqnired for the design, engineering, development, production, and test, and prototyping of a software system. The software documentation process covers user requirements, functional, and technical aspects of the software development. After development, different test phases are performed to verify installation, operation, and performance of the software. A business acceptance from the customer finally leads to implementation of the software. 

Status of test results and associated review records (indexed, organized, maintained, followed-up on failure) (see Appendix N) Involvement of QA function (as witnesses and/or reviewers) Independence and qualifications of testers and reviewers Accuracy of, and conformance to, relevant test procedures Control of test software, test data, simulators Use of testing tools (documented, controlled)... 

IV.60. Documented measures should ensure that tools, gauges, instruments, test software and other inspection, measuring and test equipment, and other devices used in determining conformity to acceptance criteria, are of the proper range, type, accuracy and precision. They should be properly handled and stored, controlled, calibrated and adjusted at specified intervals to maintain accuracy. Records of calibration should be maintained and be adequate for traceability of measurement, to national or international standards, when necessary. When deviations beyond prescribed limits are detected, an evaluation should be made of the validity of previous measurements and tests, and acceptance of tested items reassessed. 

The results of the application software integration testing shall be documented. If there is a failure, the reason for the failure and corrective action shall be included in the test results documentation. Any change to the software shall be subject to a safety impact analysis. 

The system software and components will be delivered and installed, usually by the vendor s staff and any tests undertaken documented by them. 

Simple regression analysis tends to produce inferentials that are arithmetically simple and may therefore be readily built into the DCS using standard features. More complex regressed types, such as neural networks, will require a separate platform and probably some proprietary software. They can therefore be more costly. First-principle models may be provided in pseudo-code that the engineer can convert to code appropriate to the DCS. This with its testing and documentation can be time-consuming. Inferentials delivered as black boxes may require less implementation effort but can only be maintained by the supplier. 

Validation of a chromatographic system is required by numerous quality assurance systems. For this purpose hardware, firmware, software and the analytical method used for analysis should be validated. Moreover, the chromatographic system needs to be tested against documented performance specifications for a given analytical method (system suitability test). Besides the prerequisites of a chromatographic separation, such as tailing factor, column... 

Airworthiness is generally known as the capabUity for fitness to fly. Airworthiness is the demonstrated capability of an aircraft, aircraft subsystem, or aircraft component to function satisfactorily when used within prescribed limits on the aircraft. Generally, flight clearances are prepared and issued for hardware and software documenting their level of airworthiness, which allows (or disallows) for flight with or without limitations. The demonstrated condition is usually achieved by a combination of analysis and testing. An... 

The serial numbers, model codes and embedded software revision codes are all logged to the test record document. The revision codes of the configuration or application software build are logged. 

The software documentation (Item 5 below) required to enable a qualified user to perform the applicable analyses, independent of any additional information, along with a recdrd.of all code modifkations, shall be readily available for the life of the reactors. Any significant differences between the reisuTts of standard test problems used to analyze software and the analysis results oh record shall be documented with explanations Where available and submitted to DOE for review. 

We are confident that any user of this combined evaluation technique, as well as the development of future test standards for manual ultrasonic testing will benefit from this result, because it allows a greater flexibility in the applicable method without loosing reliability. Often an expensive production of a reference block can be avoided and therefore testing costs are reduced. Since all calculations are performed by a PC, the operator can fully concentrate on his most important duty scanning the workpiece and observing the A-scan. Additional time will be saved for the test documentation, since all testing results are stored in the instrument s memory (the PC s hard drive) with full link to the Software World (Microsoft Word, Excel, etc.). 

The software US-SCAN 3.0 (IBT GmbH, Ober-Ramstadt, Germany) provides all functions of a portable flaw detector and a powerful ultrasonic imaging in A-, B-, C- and D-scans. Not only motor driven scanners can he used, but also manual scanning systems with encoders. Further documentation and test reports can be carried out with Windows software. 

The hardware and software used to implement LIMS systems must be vahdated. Computers and networks need to be examined for potential impact of component failure on LIMS data. Security concerns regarding control of access to LIMS information must be addressed. Software, operating systems, and database management systems used in the implementation of LIMS systems must be vahdated to protect against data cormption and loss. Mechanisms for fault-tolerant operation and LIMS data backup and restoration should be documented and tested. One approach to vahdation of LIMS hardware and software is to choose vendors whose products are precertified however, the ultimate responsibihty for vahdation remains with the user. Vahdating the LIMS system s operation involves a substantial amount of work, and an adequate vahdation infrastmcture is a prerequisite for the constmction of a dependable and flexible LIMS system. 

To ensure that QC and testing procedures are followed a quality control manual should be implemented. It is a document usually setup in a computer s software program that states and provides the details of the plant s quality objectives and how they will be implemented, documented, and followed. 

Yet under the original requirements of 21 CFR Part 11 both companies would have had to conduct extensive test on the software to write and implement eight to ten standard operating procedures to document the requirements, development, and change history of the code and to record and archive all records. In this case, as in so many, such an investment in time and dollars would have been justihed for the pacemakers but wasted in the case of the tongue depressors. 

---