Quality Testing

Quality is delighting customers


Software Change Management

The System Development Life Cycle (SDLC) is a methodology for the development and implementation of automated systems. The SDLC is used for mainframe developed systems and must be applied to micro based systems as well. Each organization should establish a SDLC methodology and assign responsibility for each phase of the cycle so that system design, development, and maintenance may progress smoothly and accurately.
Review Procedures

1. Review system documentation

2. Ensure a formal documented change management process exists and is maintained to reflect the current process

a. Review policies and procedures for the following:
i. Accountability for managing and coordinating changes
ii. The change management flow within the organization
iii. The change management responsibilities of each organization function
iv. The deliverables from each organization component
v. Specific timetables for reviewing and scheduling planned changes
vi. Specific timetables for the retention of historical records
vii. The handling of all changes, including change back-outs
viii. The circumstances when normal change management controls can be waived (such as emergency changes) and the procedures that exist.

b. Is there a process to update user/system documentation as a result of the changes made

c. Determine if a process exists to maintain the change management procedures

3. Ensure change requests are properly initiated and approved.

a. Verify a methodology is used for initiation and approval of changes and obtain a copy of the change request form
b. Ensure the request form includes:
i. Name of requestor
ii. Phone number and department
iii. Requestor’s signature
iv. Reason for change
v. List of modules that need to be changed (identification of change
vi. Supervisor’s name
vii. Supervisor’s approval
c. Evaluate the process used to control and monitor change requests
d. Review and evaluate the procedures for performing a needs analysis

4. Ensure code modification and development is performed in a segregated, controlled environment (separate from the production environment)

a. Ensure all changes are applied to the latest production version of code
b. Verify code is modified and/or developed in an area separate from testing/quality assurance and production
c. Determine if version control software is being used and procedures exist
i. Can programs be checked out by more than one programmer at a time
ii. Are history records kept of code check-ins/outs and deletions
iii. Is code checked into the software ever reviewed by management to ensure it is the same as what is in the production environment

5. Ensure changes made to applications/systems are adequately tested before being placed into production

a. Verify code is tested in a segregated/controlled environment, separate from development and production
b. Determine how code is moved into the testing/QA environment
c. Determine who moves the code into the testing/QA environment
d. Determine a process exists to "freeze" code once migrated into the testing/quality assurance environment to ensure no further changes can be made to the code while awaiting User acceptance
e. Determine to what extent the User is involved in the testing process
f. Ensure the test results are reviewed and approved by the User and verify the method of User acceptance
g. Verify the existence of back-out procedures. These procedures should outline the process used to back code out of the testing/QA region, in the event the original changes are not approved by the User and additional modifications are necessary
h. Ensure a process exists to document problems encountered during this phase of the change methodology and determine how problems are followed-up and resolved

6. Ensure only authorized and approved software is moved into the production environment

a. Verify procedures exist to ensure the approved code from the test environment is the version moved into production
b. Determine who is responsible for migration of code into production
c. Determine how code is into implemented to the production environment
d. Verify the existence of back-out procedures. These procedures should outline the process used to back code out of the production
e. Determine if a process exists to reconcile changes and verify who performs this process and how often the process takes place

7. Ensure a process exists to control and supervise changes made in an emergency situation

a. Determine a process exists and is documented
b. Determine if emergency user ids are in use. If so, ensure a process exists to enable and disable them (at a minimum 2 people should be involved in this process - if it is not automated
c. Ensure an audit trail exists of all emergency Id usage and that it is independently reviewed
d. Ensure emergency changes are approved by appropriate levels of management prior to implementation into production
e. Determine that procedures require that emergency changes be supported by appropriate documentation (e.g., evidence of management approval, code review) within one business day after the emergency is resolved
f. Verify a list of Business/Operations Management allowed to approve emergency changes exists. Programmers should not be able to initiate emergency changes
g. Determine if the approval of Business/Operations Management is required prior to the implementation of an emergency change
h. Ensure back-out procedures exist. These procedures should outline the process used to back code out of the production
i. Determine the number of emergency changes made during the audit period under review. Analyze the volume of emergency access requests and determine if it appears to be excessive

8. Non-emergency change management compliance testing

a. Select a sample of non-emergency changes (application/system) that have occurred during the period of review from the source program library directory
b. Using the sample selected, verify the following:
i. All changes have been formally initiated, completely documented, and approved by someone other than the requester
ii. All changes have documentation stating code is ready to be moved from development to testing/QA with the authorized approvals
iii. All changes have documentation that a needs analysis assessment has been performed
iv. All changes have documentation stating that they have been received and reviewed by a QA type function and approved by the User prior to installation into production
v. Documentation exists showing a source comparison was performed prior to installation into production. A source comparison will determine if the current production source matches the current load program
vi. All documentation lists a date that agrees with the date of the production update
c. For the sample selected, perform a source code comparison of the code maintained in the version control software and the code in the production environment
d. Examine the test script of a sample of changes to determine if testing is adequate
e. Obtain a copy of the change reconciliation report. Verify evidence exists for the review and reconciliation of changes

9. Emergency Change Management Compliance Testing

a. Select a sample of emergency changes that have occurred during the audit period under review. Determine if any of the changes should have gone through the non-emergency change process
b. Using the sample, determine if the changes have been made in compliance with the established procedures
c. Using the sample, verify that the date on the approval documentation is not more than one day after the date on the executable module
d. For the sample selected, perform a source code comparison of the code maintained in the version control software and the code in the production environment

10. Ensure access to change management libraries is restricted to authorized personnel
a. Obtain an access list of the application and system, production and test/QA source, and executable libraries/directories
b. Review security rules to ensure access has been restricted to authorized individuals

Note: . Hi all, the blog details are some of them are collected and some have been prepared by me.Please anybodies has objection or doubt then msd298@gmail.com


--Mahesh Dhule

Views: 3

Comment

You need to be a member of Quality Testing to add comments!

Join Quality Testing

TTWT Magazine

Welcome to Quality Testing!

Keith Klain

 Director - Head of Global Test Center at Barclays

Advertisement

Submit A Job

Submit A Tool

Advertisement

Videos

  • Add Videos
  • View All

Badge

Loading…

© 2013   Created by Quality Testing.

Badges  |  Report an Issue  |  Terms of Service