Declaración de conflicto de interés

Q: Do I have to validate Windows (or Linux, or…)

A: The operating system on which the application runs could well introduce errors or cause the application to function in an unexpected manner. But how would you validate an operating system? Generally, it should be sufficient to validate the application on the target operating system (remember the rule about testing in the intended environment).

If the application is to run on multiple operating systems, it's good practice to qualify the installation on each operating system. Most companies have server qualification procedures that ensure that each build has been done consistently and is hosted on a specific (qualified) hardware platform.

Q: Do I have to validate my network?

A: A qualified network is expected when that network is hosting a validated system. Generally, a network need not be validated to ensure validation of a software application. There could be cases where network validation is necessary, but that's outside the scope of software validation.

Q: What about hosted software?

A: Hosted software—software resident on another company's equipment and execution is controlled via the internet or some other networking protocol—is a relatively new idea. If the software meets criteria to require validation (affects quality, and so on), you are responsible for

validation. Typically, you as the client would establish contractual requirements for the hosting company to meet basic standards for life cycle management, change control, backup and recovery, and so on.

You might perform validation testing yourself or you might contract with the hosting company to do so. In this situation, it's extremely important that the contract be set up to require the hosting company to notify you of any changes (to the software, the environment, and so on).

And should changes occur, an assessment would be required to determine if re-validation is warranted. Many companies realize the potential exposure for regulatory violations and tend to avoid using hosted applications.

Q: What about distributed applications? Is validation required on every installation?

A: A distributed application is a system installed on multiple computers and networks in multiple locations. If you can prove that each install on each system is equivalent, then you can test on one system and verify a subset of the others. In general, you must prove the specification on each computer has the minimum requirements and the software on each is the same version. If that's not possible or is impractical, you may be able to show equivalence and minimize testing on other systems (for example, it may not be necessary to test the user interface on every system), however systems such as those that are safety-critical should

validation apply to every installation. This applies to both clients and servers.

Q: Does migrating data from one validated system to another require validation?

A: Generally, yes. The data is part of the system, so it constitutes a change in the system. The new system should be tested to ensure the migration completed as expected. If there are tools involved in the migration, then those tools would likely need to be validated as well.

Q: What's the best way to organize the validation package?

A: Whatever works for your company! There is no right way. For regulatory purposes, it should be readily retrievable in human readable format (and complete). As long as those conditions are met, you've done it right. This document outlines a generally accepted approach, but it's by no means required.

Q: Are screen shots required to support test results?

A: No, but screen shots are a good way to show that the expected results have been met. There's a tendency in practice to overdo it and have screenshots for every action. This results in volumes of data and makes it difficult to find specific data when needed. It also adds an overhead in properly managing and maintaining the data. Judicious usage of screenshots can greatly enhance justification for meeting expected

sometimes helpful, but when screenshots are used for nearly every test step, then it more or less undermines the actual tester signing and dating each test step and is also cumbersome for reviewers, especially those (such as QA) who aren't entirely familiar with the system in the first place.

Q: I have a system that has software controlling the fill volume of a vial. If I change the amount of volume for the fill process (a system parameter), do I have to re-validate?

A: It depends. There's more to this question than on the surface. If you do a good job of validation, you have validated the system to support a range of configurations, not just a static configuration. Take, for example, a system that assesses a volume of fluid dispensed to a vial. Initially, the system is only expected to support filling a 20mL vial. An astute validation analyst, though, decided to validate the system to verify functionality across a range of fill volumes, including no fill. Then, when the company determined a need for a vial filled with only 10mL of fluid, no additional validation was required. The system had already been validated for this configuration. Had they initially validated for a filled vial only, additional validation for the new configuration would be required. What if the company decided to use a different fluid? If the system hadn't been validated for a range of fluids (viscosity, specific gravity, and so on), additional validation is likely needed.

Deviations are when an actual result differs from an expected result;

these are often test failures. Deviations could occur due to a technical reason, or simply a typographical error on the part of the test script or document author.

Deviations could cause testing to stop cold while the deviation is analyzed and a solution determined. All deviations should be immediately raised to appropriate personnel (test co-ordinator, Quality Assurance, management). Deviation handling is defined by company policy, but deviations generally should:

· Stop testing until corrective actions are implemented; often in the case of typos, the tester can simply make a note in the comments section and continue;

· Allow testing to continue, but the deviation must be corrected prior to launch/release;

· Allow testing to continue, but the deviation will be acceptable for release (and will be corrected in a later release);

· Be rejected if the deviation is a protocol error and the protocol

Appendix A: