1.1. NAME functionality related to the SCRIPT NAME as per ... · PDF file216-9813.02-001 Validation Plan, Microsoft Dynamics AX 2009 ERP System 202-9813.10-001 Hardware Specification,

Microsoft Dynamics AX 2009 ERP System Operational Qualification (OQ)

Control # 214-YYZZ.##

208-9813.732 /001, System Access ID/Password, Internal Use Test Protocol, 01/27/10 Page 1 of 15

Document Tracking

Dept. Responsibility: Respon. Function Last DCO #: xxxxxxx Release Date: xx/xx/xx Unless stamped Distribution Copy and dated, this document is for reference only. User is responsible for obtaining current revision. For a controlled copy, please contact by email DL- Doc Control.

1. Purpose

1.1. The purpose of this operational qualification test script is to test URS SECTION NAME functionality related to the SCRIPT NAME as per section 6.2.X in Customer User Requirements Specification (URS) document number

#200-9813.01-00.

2. Scope

2.1. The scope of this test protocol includes the following user requirement (s):

• REQ-000 - The system shall require users to enter both a User ID and password before granting access

• REQ-000 - The system shall require the account/password combination to be unique for each user account.

3. Reference Documents

Number Description 200-9813.01-001 User Requirements Specification (URS)

102-0600.05-001 Software Assessment, Microsoft Dynamics AX 2009 ERP System

216-9813.02-001 Validation Plan, Microsoft Dynamics AX 2009 ERP System

202-9813.10-001 Hardware Specification, Microsoft Dynamics AX 2009 ERP System

202-9813.11-001 Specification Trace Document, Microsoft Dynamics AX 2009 ERP System

800286-001 WI, Quality Data Recording

4. Definitions

Acronym, Abbreviation

Definition

ABA American Bankers’ Association

ACH Automated Clearing House

AMT Alternative Minimum Tax

AP Accounts Payable

AQL Acceptable Quality Level





Definition

AR Accounts Receivable

BFS Back from Sterilization

BOL Bill of Lading

BOM Bill of Materials

CA-AMT California Alternative Minimum Tax

CAPA Corrective and Preventive Actions

CAPARB CAPA Review Board

COC Certificate of Compliance

COS Cost of Sales

CRM Customer Relationship Management

DAX Microsoft Dynamics AX

DOM Date of Manufacture

ECO Engineering Change Order

ECR Engineering Change Request

eDHR Electronic Device History Record

EDI Electronic Data Interchange

ERP Enterprise Resource Planning

ESD Electrostatic Discharge

FCA Field Corrective Action

FCA Field Corrective Action

FGI Finished Goods Inventory

FIFO First-in, first-out

FMEA Failure Mode and Effects Analysis

FRU Field Replaceable Unit

FSA Field Service Activity

FSE Field Service Engineer

FSR Field Service Report

GAAP Generally Accepted Accounting Principles

GL General Ledger

ICC International Chamber of Commerce

INFS In for Sterilization

KPI Key Performance Indicator

LDPM Limited Distribution Product Matrix





Definition

LHR Lot History Record

MDR Medical Device Reporting

MDV Medical Device Vigilance

MES Manufacturing Execution System

MRB Materials Review Board

N/A Not Applicable

NCR Non-Conformance Report

OFS Out for Sterilization

OOSR Out-of-specification Report

Part 11 The chapter of the Code of Federal Regulations that applies to the use of electronic records and electronic signatures that are used in the fulfillment of record requirements set forth in FDA regulations.

PMDA Pharmaceuticals and Medical Devices Agency

PO Purchase Order

PSR Product-Specific Rules

QA Quality Assurance

QAD QAD MFG/PRO Enterprise Resource Planning System

QE Quality Engineer

QFI Quality Final Inspection

QRI Quality Receiving Inspection

QUAR Quarantine

RA Regulatory Affairs

RBFS Refurbished, Back from Sterilization

RFGI Refurbished Finished Goods Inventory

RFID Radio Frequency Identification

RFS Ready for Sterilization

RMA Return Merchandise Authorization

ROFS Refurbished out for sterilization

RTest Refurbished

RTS Return to Stock

RTV Return to Vendor

RWIP Reconditioned Work In Progress (or Process)

Sensitive Account A customer who has submitted three or more complaints within the previous 90 days.





Definition

SO Service Order

SOP Standard Operating Procedure

SOX Sarbanes-Oxley

UOM Unit of Measure

USD U.S. Dollars

VA Customer Atlanta

VB Customer Billerica

VCR Customer, Costa Rica

VE Customer Europe

Ver. Version

VJ Customer Japan

VoE Verification of Effectiveness

VRC Customer, Rancho Cordova

WI Work Instruction

WIP Work In Process (or Progress)

XBRL eXtensible Business Reporting Language

5. Responsibilities

5.1. Owner – Responsible for organizing the validation and/or implementation effort. Approves test script changes once the test protocols are approved

5.2. Tester – Executes the test protocol, marks the realized test results, documents the actual result when it differs and seeks approval when deviations to the protocol are necessary

5.3. Reviewer – Reviews the executed test protocol, review proof of execution data, assures compliance to good documentation practices, and marks the overall test case result.

5.4. Quality Assurance – Responsible for approving protocol deviations

6. Materials/Equipment Used

6.1. Raltus Procedure Capture® software was used to capture and run all OQ test protocols.

7. Procedure




The execution methodology used to run the test protocols is defined below. The “Test Corrections”, “Tester” and “Reviewer” sections are included in all test protocols.

7.1. Protocol

7.1.1. Test Corrections – Minor test inconsistencies such as typo’s, spelling errors, obvious omissions shall be corrected and initialled and dated before completing the test. A comment as to why the correction was made can be added to the “Comments” sections at the end of the test case.

7.1.2. Tester - For each test case below, the tester shall execute the test steps using Raltus Procedure Capture® as written. When the “Expected Results” are realized for the test step, the tester will circle the “P” in the “Result” column and go on to the next step. When the “Expected Results” are not realized for a test step, the tester shall circle the “F” in the result column, note the actual result in the “Result if Failed” column, and then consult with the Project Lead to determine whether execution of this procedure (and others) will be suspended, and if so when it may be resumed or restarted.

7.1.3. Reviewer – The reviewer will review the executed test cases once protocol execution is complete. The test case results at each test step and all test documentation shall be reviewed. The reviewer is to confirm that all results are properly marked and that all documentation complies with Good Documentation Practices. After reviewing all test steps for the test case, the Reviewer shall mark “Pass” in the “Test Status” box if all test steps passed, or mark “Fail” if any test step did not pass, sign in the “Review Section” and enter the date the review occurred.

7.2. Test Case Standards

The following paragraphs below define the set of standards developed to assist in ensuring complete test coverage and consistency in test case creation. The test case standards are documented here.

7.2.1. All requirements will map to tests

7.2.2. N/A maybe used in the Req ID column if the test step is not verifying the actual requirement, but is necessary to create a state the requirement under test can be examined

7.2.3. Each requirement will have positive and negative tests when applicable

7.2.4. Field limits will be tested when noted in the requirements

7.2.5. Test data will be prepared and entered into the database before testing begins

7.2.6. Test data will be documented and provided to the test case originator for use in the creation of test scripts




7.2.7. Terminology will be used as defined by the module owner. Each test protocol will document standard definitions in the definitions section of the protocol

7.2.8. Test Cases are to be stand alone when ever possible. If a prior test is required to be executed before the next test case can begin the test case must state that in the first step of the test case.

7.2.9. All tests will contain an expected result.

7.2.10. All test cases will be executed on the test system before they are finalized and check into Agile. (This is part of the beta testing activity)The System shall have an IQ/OQ.

7.2.11. All test protocols have been reviewed and are approved in Agile

7.2.12. All requirements are frozen and approved in Agile…

7.2.13. SOP's and WI's being used during validation and/or implementation are approved in Agile.

7.2.14. Records are retained in accordance with 800176-001 Control of Quality Records.

7.3. Test Case Corrections, Deviations, and Documentation

The purpose of this section is to describe the general requirements that must be adhered to during the test case execution.

7.3.1. Test Corrections – Minor test inconsistencies such as typo’s, spelling errors, and obvious omissions shall be corrected and initialed and dated before completing the test. A comment as to why the correction was made is added to the “Comments” section at the end of the test case.

7.3.2. Test Deviations – Non trivial errors in test steps require a Deviation. When a test deviation is necessary, the tester will work with the product owner and management to document the deviation in the “Deviation Section” at the end of the test case. The product owner and management will then review the deviation section before the test is resumed and sign and date the Deviation. Deviations can include, but are not limited to test failures that have an acceptable work around, test that do not follow the required sequence, and incorrect expected results.

7.3.3. Test Documentation – All test execution activities shall be documented by the tester and signed and dated. Hardcopy documents (such as screen prints or reports) that are attached as evidence of execution shall comply with WI, Data Recording Requirements (800286001). For comments, observations, statements, that are written anywhere on any part of a protocol, for any reason, the tester's initials and date shall be included immediately following the written text or notes.

7.4. Test Cross Reference




Each test case in the test protocol demonstrates compliance to defined behavior as identified within the User Requirements Specification # 200-9813.01/002.

8. Test Cases

8.1. Participants – All testers and reviewers will print and sign their name with their title on the executed protocol.

Print name Sign name Title

8.1.1. _________ ________ ___________

8.1.2. _________ ________ ___________

8.1.3. _________ ________ ___________

8.2. Configuration – The test configuration will be documented on the executed protocol. Software shall include version information.

8.2.1. ______________________________________________________

8.2.2. ______________________________________________________

8.2.3. ______________________________________________________

8.2.4. ______________________________________________________




8.3 Operational Qualification Test

Test Case Description The purpose of this test is to....

STEPS

No. Procedure Step Expected Result Actual Result P/F Initial

1.

Left Click

Click on Siebel at bottom




2.

Left Click

Go to the Accounts screen at top

3.

Left Click




4.

Left Click

5.

Left Click




6.

Type

Marriott

7.

Left Click




8.

Left Click

9.

Left Click




10.

Left Click

11.

Screen Check




12.

Screen Check

13.

Left Click




Comments (Required if test fails) Additional comments or special results are recorded here. Test Deviations: Management Approval: Date: Attestation I, the undersigned, performed the above Test Case and certify that all information provided by me on this Test Case is complete and accurate. Performed by:

Test Date:

Test Status: PASS FAIL Reviewed by:

Review Date: