Establishing a Test Policy

A testing policy (Figure 1) is a management’s definition of testing for a

department. A testing policy involves the following four criteria:

1. Definition of Testing – A clear, brief, and unambiguous definition of testing.

2. Testing System – The method through which testing will be achieved and
enforced.
3. Evaluation- How information services management will measure and
evaluate Testing.
4. Standards – The standard against which testing will be measured.

Good testing does not just happen, it must be planned; and a testing policy
should be the cornerstone of that plan. Figure 1 is a simplistic testing policy that
an IT department could adopt. A good practice is for management to establish
the testing policy for the IT department, then have all members of IT
management sign that policy as their endorsement and intention to enforce that
testing policy, and then prominently display that endorsed policy where it can be
seen everyone in the IT department.

Year 2000 Testing Policy

ABC Information Service Department

Testing Definition
Determination that all Computer Systems are Year 2000 compliant, including
internally and externally developed software and software embedded in
computer chips.

Testing System
Development and execution of a year 2000 test plan in accordance with
departmental procedure and user requirements.
Measurement of Testing
Cost of Year 2000 date failures.

Testing Standards
Every software system to be certified Year 2000 compliant by 12/31/99

Philips Jones
George Wilson
Elizabeth Charney
Max Hartman

Figure 1.
Information services management normally assumes that their staff understand
the testing function and what they, management, want from testing. Exactly the
opposite is true. Testing is not clearly defined, nor is management’s intent made
known regarding their desire for the type and extent of testing.
Information services department frequently adopt testing tools such as a test
data generator, make the system programmer/analyst aware of those testing
tools, and then leave it to the discretion of the staff how testing is to occur and to
what extent. In fact, many anti-testing messages may be directly transmitted from
management to staff. For example, pressure to get projects done on time and
within budget is an anti-testing message from management. The message says “
I don’t care how you get the system done, but get it done on time and within
budget,” which translates to the average systems analysts/programmer as “ Get
it in on time even if it isn’t instead.”

Methods

The establishment of a testing policy is an IT management responsibility. Three

methods can be used to establish a Testing Policy:

1. Management Directive – One or more senior IT managers writes the

policy. They determine what they want from testing, document that into a
policy, and issue it to the department. This is an economical and effective
method to write a testing policy; the potential disadvantage is that it is not
an organizational policy, but rather the policy of IT management.

2. Information Services Consensus Policy – IT management convenes a

group of more senior and respected individuals in the department to jointly
develop a policy. While senior management must have the responsibility
for accepting and issuing the policy, the development of the policy is
representative of all the IT department, rather than just senior
management. The advantage of this approach is that it involves the key
members of IT department. Because of this participation, staff is
encouraged to follow the policy. The disadvantage is that it is an IT policy
not an organizational policy.

3. Users Meeting – Key members of user management meet in conjunction

with the IT department to jointly develop a testing policy. Again, IT
management has the final responsibility for the policy, but the actual policy
is developed using people from major areas of the organization. The
advantage of this approach is that it is a true organizational policy and
involves all of those areas with an interest in testing. The disadvantage is
that it takes time to follow this approach and a policy might be developed
that the IT department is obligated to accept because it is a consensus
policy and the not the type of policy that IT itself would have written.

Testing is an organizational responsibility. It is recommendation of the author that

a user committee to develop a testing policy. This meeting serves the following
purposes:
It permits all involved parties to participate in the development of a testing policy.

It is an educational process where users understand the options and costs

associated with testing.

It clearly establishes for all involved departments that testing is an organizational

responsibility and not just an IT responsibility.