Smartlogic

Menu

Author: אביב צברי

Management of Test Incidents Exceptions

Posted on by אביב צברי

                        GAMP- Management of Test Incidents Exceptions

This article was written by Ilan Shaya a world specialist in validation, automation & control

Development life cycle of a system of product containing SW often involves unexpected incidents, predominantly in the testing phase. Whilst defects and failures are unlikely to ever be totally eliminated, occurring incidents should be promptly and correctly dealt with by the test team to minimize the likelihood of passage of avoidable defects into production environment

Incident notifications may be received via different media (e.g., paper, e-mail, or a dedicated incident reporting system), and may, therefore, require variations in the way they are handled. Thus, an Incident Management Plan (or Procedure), which defines the approach for dealing with individual input types, should be prepared and communicated across the test team before starting any testing. In small projects, this plan may form a sub-section of the overall Quality Plan/

:The aim of any test incident management process should be

To establish and operate an effective service to manage the recording and subsequent handling of test incident, and any other observations noted by the testers

To act as a single point of contact between end users and problem solvers, service suppliers, system developers and testers

To handle all incidents in a consistent manner

To demonstrate that all incidents have been properly resolved

To report performance against the service levels set out in the pertinent Service Level Agreements -SLA

Details of all incidents should be logged centrally for each project, and each incident should be allocated a unique reference number, which should be communicated to the relevant parties for future reference and tracking

GAMP – Test Management Tools, Coverage & Traceability

Posted on by אביב צברי

  GAMP – Test Management Tools

אילן שעיה Ilan Shaya
Ilan Shaya CEO , control and automation specialist and designer

This article was written by Ilan Shaya a world specialist in validation, automation & control

Computerized test management tools are extremely useful for testing large or complex systems, or in organizations where there is need for ongoing testing of SW and computerized systems

:Such tools generally improve the efficiency of test processes, by managing activities such as

Requirements traceability

Test script development, review and approval

Test planning

Test execution, including automatically running test cases

Test results, and test evidence capture and management

Test case review

Test incident management

Overall test management using test monitoring tools

Most modern test management tools provide the ability to configure test process workflows and user roles, and significantly reduce the need for paper based test records

For use in pharmaceutical and related industries, such test management should be properly verified and the integrity of test records should be assured. See GAMP 4, Appendix M4

:The use of such tools is recommended for organizations that

Implement large or complex system with potential multiple rounds of regression testing during the system life cycle such as ERP, LIMS or desktop client images

Develop expertise in testing computers and SW across all business areas, and have an opportunity to develop expertise in the use and support of a test management tool

                          Test Coverage and Traceability

The Test Plan or Strategy should require clear, documented traceability between the requirements outlined in the controlling specifications and undertaken tests. This traceability, once completed, should demonstrate that every stated has been tested, and show the mutual correspondence between the items

It is important to initiate requirements traceability as early as as possible in the project, typically after URS approval

Traceability to requirements should be maintained at the Test Case or Test Script level. If the test covers multiple requirements, further breakdown within the test steps may be considered to demonstrate where a specific requirement is tested.

:A Requirement Traceability Matrix (or equivalent provides the following benefits for testing

Documented test coverage of all critical (GxP) requirements

Determination of specific testing documents that require updating as a result of changes

Reduction of redundancy (and, thus, of effort) in Test Specifications or Protocols

Ease of presentation to regulators, in order to demonstrate the completeness of testing within the development process of an application

Not all requirements may be traceable to Test Case or Test Script. Some requirements may be verified instead of tested, but verification activities and documents can also be included in requirement traceability – see GAMP 4, Appendix M5, for further details

GAMP – Test Phases and Sequencing

Posted on by אביב צברי

Good Automated Manufacturing Practice (GAMP) – Test Phases and Sequencing

 This article was written by Iian Shaya, validation,automation and control expert

In developing any system, whether hardware (HW), firmware (FW) software (SW) or any combination of these, it seems common sense to start the verification of correct functioning with the smallest possible module (or unit) within the system. With the confidence that each module operates successfully in stand-alone mode, investigation of subsequent failure can focus the interfacing or integration of these modules.

As the verified integrated modules are combined with other verified modules, the number of interfaces grows, but testing can usually be restricted to verifying these interfaces and their impact on the overall functionality of the system. This system of modular testing follows the life cycle described in GAMP 4

Depending on the size and type of system, there may be several phases that support the validation process. These may cover all or some of them:

Test carried out by the supplier

Formal Factory Acceptance Testing (FAT) at supplier premises

Installation and commissioning testing, usually done by the supplier

Formal Site Acceptance Testing (SAT) to verify that the system meets the user requirements

Installation Qualification –  IQ

Operation Qualification – OQ

Performance Qualification – PQ

IQ is typically conducted during the build of a qualified environment. OQ and PQ of a system or application are typically conducted as part of qualifying a wider manufacturing or business process. The relationship of the IQ, OQ and PQ to the testing of systems or applications should be clearly defined.

:For each project, the Test Plan or Strategy document should define the test phases required, including

Location and timing of the tests.

Responsibilities (for example, for test execution, review and necessary training

Required test coverage, based on risk assessment

Overview of the test environment

Documentation required, base documentation, such as Design Specifications, Test Specifications or Protocols, Test Results Proforma, and Test Results required on test completion

 This article was written by Iian Shaya, validation,automation and control expert

אילן שעיה Ilan Shaya

Computerized System Validation

Posted on by אביב צברי

ולידציה -Computerized System Validation

 This article was written by Iian Shaya, validation,automation and control expert

Each system has a specific life length dependent on the time taken for the system to become outdated; this life length is called System Life Cycle – SLC

The SLC is defined as an organized method to plan develop, test, modify and maintain a computer-based system

:The SLC requires the following

Unit tests – The test protocols shall be traced to low level design document and will be approved by the user prior to execution. The approval of the report shall be performed by representatives of the user’s validation team, IT QA

Management

Requirements

Design

Implementation coding

Integration

Installation

Operation and support

Maintenance

Change control

Management

Management must identify and provide an appropriate validation environment. Refer to Code of Federal Regulations (CFR) 820.20 which is a law issued by the US

:A plan must be developed to include

Validation tasks for each life cycle system

Methods and procedures for each validation task

Criteria for initiation and completion of each validation task

Inputs for each validation task

Outputs for each validation task

Criteria for defining and documenting outputs in terms

Requirements

:Electronic Records

The system/product should ensure cover of the following requirements, related to Electronic Records

The system/product must generate accurate and complete copies of records in both human and electronic form

The system/product must protect records to enable their accurate and ready retrieval throughout the records retention period

The operational system/product checks must enforce the proper sequencing of steps in a process, as appropriate

:The system/product must ensure that only authorized individuals can

Criteria for defining and documenting outputs in terms

Use the system, logical access

Electronically sign a record

Access the operation or computer system input, including time/date and idle session

Access the operation or computer system output device

Alter a record

Audit Trail

The system must cover the following requirements related to Audit Trail

The audit trail must be secure

The audit trail must be computer generated

The audit trail must include time and date stamp

:The audit trail must independently record the date/time of operator entries and actions that

Create electronic records

Modify electronic records

Delete electronic records

The system/product must ensure that changes to electronic records cannot obscure previously recorded information

The audit trail records must be maintained for at least as long as the retention of the underlying records

The audit trail records must be available for review and copying

Electronic Signatures – ES

The system will relate to ES (linkage between the record and the signature) during the working process under the following requirements

The ES must contain the printed name of the signer

The ES must contain the date and time of signing

The ES must contain the meaning of the signing, such as approval, review, responsibility etc

The ES must include a part of any human readable form of the electronic record, such as electronic display and/or printout or report

The 3 items above must have the same controls as for electronic records

The signatures linked to their respective electronic records must ensure that these records cannot be cut, copied, or otherwise transferred by ordinary means for the purpose of falsification

The system must ensure that the electronic signature is unique to one individual and not be reused by, or reassigned to, anyone else

The electronic signature must employ, at least 2 identification components, such as identification code and password

The system must enable customization of workflow signing rules (using one or all signature components in different scenarios), when an individual executes a series of signings during a single or continuous period of controlled system access

The system must be contained into a unique Digital Signature (biometrics, token, cards, cryptographic symbols etc

Controls for Identification Codes/Password

The combination of the identification code and password must be unique

The combination of the identification code and password must be revised, e.g., to cover such events as password aging

Unauthorized use of password identifications and devices must be reported to the system security unit and/or management, as appropriate

 This article was written by Iian Shaya, validation,automation and control expert

אילן שעיה ilan Shaya

ICS Security Strategy

Posted on by אביב צברי

To achieve the level of protection needed for industrial and critical networks, secu­rity needs to grow from a collection of disparate technologies and practices to an effective business process. Smart Logic recommends organizations to look at three dimensions when deploying a security strategy and solution

Policies

Security starts with a widely understood and well-defined policy—closely aligned to business needs rather than a collection of system-level checks and disparate technologies. Policies should take into account that the priority is the business and suggests way to conduct in a secure manner as part of the business policy instead of appearing in a completely different context.

 People

Users of computer systems are a critical part of the security process. It is often users who make mistakes that result in malware infections and information leak­age. Organizations should pay much attention to the involvement of users in the security process. Employees need to be informed and educated on the security policy and their expected behavior when surfing the Internet or sharing sensitive data. At the same time, security should be as seamless and transparent as pos­sible and should not change the way users work.

 Enforcement

Deployment of ICS security technology solutions such as security gateways and end­point software is critical for automated analysis of traffic, prevention of attacks and regulation of work procedure. It should meet three main goals:

a) Ensuring the security of the SCADA network devices perimeter and interface points

– It is recommended to maintain physical network separation between the real time components of the SCADA network (e.g. PLCs) and other networks.

– Security Gateways should be installed at all interconnects, ensuring that only relevant and allowed traffic is entering/leaving the network. This validation should be done on all communication, protocols, methods, queries and responses and payloads using

o Firewall

o Application Control

o IPS – Most recommended is Smart Logic’s

o Antivirus

b) Ensuring that all workstations and portable equipment used for management and maintained is free from malware and secured

– Dual homed workstations that connect to both an internal critical network and to other less sensitive networks or even the Internet is a major risk. In cases where such configuration is mandatory

o Users must be fully aware of the risks

o Software and Security Configuration should limit the operations that can be performed on the workstation

o Strict analysis of all traffic, files and payloads must be performed in Real Time

– All workstations must be hardened and controlled by an Endpoint Security Suite including

o Firewall

o Application Control

o Port Control

o Media Authentication/Encryption

o Antivirus

c) Ensuring SCADA traffic within the perimeter is valid and free of exploit attempts

– It is recommend to filter or at least monitor all SCADA communication

– Security Gateways should be installed within the SCADA network in either in-line or tap-mode allowing:

o Firewall

o Application Control

o IPS – Most recommended is Smart Logic’s