--. - ~.. 

.. 
FOREWORD 

The computer age has brought many new challenges 

for auditors. The speed and complexity of computers, 

combined with the lack of human readable data in many 

phases of computer processing, have necessitated many 

changes in auditing techniques. This booklet describes one such technique, called "test decking." 

Although test decks have been in existence for years, 

we believe a restatement of the basic concepts, along 

with an explanation of our recent experience on automated payroll applications, will be helpful to the 

auditor who must work in the computer environment. 

A test deck is a set of simulated transactions 

which can be processed through a computer system to 

see whether proper transactions will be processed 

accurately and improper ones identified and rejected. 

This technique helps to determine whether the camputer programs process data accurately and whether 

the controls in the system can prevent improper 

results, such as exorbitant payroll checks. 

. 

However, using a test deck should not be regarded as a complete audit of a computer system. 

i 
For example, it r ill not disclose (1) invalid bi t 

properly prepared input data or (2) some changes in 

computer programs that might be made to produce 

fraudulent results. It must be supplemented with 

other procedures to provide satisfactory audit 

coverage. When used correctly, however, a test deck 

does provide a great deal of information about the 

way computer programs work. 

This booklet provides auditors with-general 

information about the test deck technique and some 

specific guidance for using it to audit Federal 

agency computer systems. The booklet is based primarily on recent experience in applying test decks 

to batch-processed payroll systems. However, the 

basic concepts and general approaches discussed can 

be applied to developing and using test decks for 

testing programed controls and procedures in any 

administrative or accounting data processing system 

which records, manipulates, and summarizes data. 

* 

Comptroller General 

of the United States 

December 1975 --____._ --- 

I ii 

DESCRIPTION AND 

ADVANTAGES AND I: 

Advantages 

Disadvantage 

DESIGN AND USE 0 

Test deck de 

Tests of 

transa 

Tests us 

Test to 

establ 

Entering tes 

Analyzing pr 

APPLYING TEST DE 

UPDATE MASTER 

Using copied 

to set up , 
Contents 

Page 

DESCRIPTION AND PURPOSE OF TEST DECKS 

ADVANTAGES AND DISADVANTAGES OF TEST DECKS 

Advantages 

Disadvantages 

DESIGN AND USE OF TEST DECKS 

Test deck design 

Tests of normally occurring 

transactions 

Tests using invalid data 

Test to violate 

established edit checks 

Entering test data 

Analyzing prbcessing results 

1 

8 

8 

11 

11 

14 

14 

16 

APPLYING TEST DECKS AGAINST PROGRAMS THAT 

UPDATE MASTER RECORDS 18 

Using copied -and/or simulated master records 

to set up a separate test file 18 
Page 

Using special audit records maintained in 

the current master file 20 

Conclusion 22 

SUMMARY OF SUGGESTED STEPS IN DESIGNING AND 

USING A TEST DECK 

APPENDIX I--HOW TEST DECKS WERE DESIGNED AND 

USED IN TWO REVIEWS OF AUTOMATED PAYROLL 

SYSTEMS 

APPENDIX 11--TYPICAL PAYROLL TRANSACTIONS TO 

BE INCLUDED IN A TEST DECK 

23 

26 

30 

DESCRIP 

A test dec 

designed to tes 

of programed co. 

computer system. 

both expected ai 

happen during at 

Before the tran: 

sults are "prede 

tion that the cc 

effective inter1 

specified) so tl 

with the predete 

Test decks 

tems test decks, 

including both n 

(2) program test 

puter programs t 

are processed an 

(In reviewing ba 

tems (see app. I 

(see app. 11) to 

accurately proce 
DESCRIPTION AND PURPOSE OF TEST DECKS 

A test deck is a set of simulated transactions 

designed to test for the existence and effectiveness 

of programed controls and procedural operations in 

computer systems. The transactions should represent 

both expected and conceivable conditions that could 

happen during actual data processing operations. 

Before the transactions are run, expected test results are "predetermined" (calculated on the assumption that the computer program being tested contains 

effective internal controls and will perform as 

specified) so that actual results can be compared 

with the predetermined results. 

Test decks are of two general types: (1) systems test decks, which test all types of conditions, 

including both manual and computer procedures, and 

(2) program test-decks, which test the logic in computer programs to determine how various transactions 

are processed and how certain controls function. 

(In reviewing batch-processed automated payroll systems (see app. I), GAO is using program test decks 

(see app. 11) to find out whether computer programs 

accurately process pay and leave data.) 
A test deck is useful for making compliance 

1 tests of a computer system’s internal controls, 

particularly when (1) much of the internal control 

system is embodied in computer programs and/or 

(2) gaps in visible audit trails make it difficult 

or impractical to trace input to output or to 

verify calculations. 

‘Test decks do not test the accuracy of file data or 

transactions. To make substantive tests of data 

and transactions, the auditor must perform manual 

tests or use a package of computer program routines 

especially designed for audit purposes. 

“Will rhe computer 

exwbitant amount ( 

for $50. OOO)?” Wit 
“Will the computer print out checks to a nonexcstent person lor an 

exGrbitant amount (say a biweekly payroll check to Donald Duck 

for $50.000)?” With a test deck you can find out. 

3 
ADVANTAGES AND DISADVANTAGES OF TEST DECKS 

The auditor should consider the following ad- ;I 

vantages and disadvantages of test decks from the 

standpoint of audit objectives and other relevant 

factors. 

ADVANTAGES 

1. A test deck can be designed for any program, 

system, or equipment. 

2. Test results can be readily checked. 

3. The test data processes either correctly or 

incorrectly. 

4. The auditor can choose the types and combinations pf transactions or procedures to 

be tested. 

5. The auditor can accept test results without 

actually tracing data through processing 

stages. 

4 

6. Extens: 

sys tern! 

prograr 

workinc 

and out 

procedi 

DISADVANTAGES 

1. A test 

applica 

designe 

2. It test 

in time 

incorpo 

would a 

as cham 

iules, I 

3. It is c( 

a good i 
6. Extensive technical knowledge of computer 

systems or the ability to write computer 

programs is not required. (However, a 

working knowledge of file structure, input 

and output formats, and data processing 

procedures is necessary.) 

DISADVANTAGES 

1. A test deck is valid only for the single 

application or program for which it is 

designed. 

2. It tests procedures only for a given point 

in time and therefore must be updated to 

incorporate any system or other changes that 

would affect the validity of the tests, such 

as changes in file structure, statutes, 

rules-, or regulations. 

3. It is costly and time consuming to develop 

a good test deck. 

5 
4. It is impractical, if not impossible, to 

design a test deck to test every conceivable 

situation in a typical administrative or 

accounting type computer system because of 

the virtually limitless variety of transactions and conditions that could occur. 

6 
7 

i 

3 
DESIGN AND USE OF TEST DECKS 

TEST DECK DESIGN 

To design an adequate test deck, the auditor 

must be familiar with (1) relevant laws and regulations and include their provisions in the simulated 

transactions and (2) data processing system procedures and input and output fqrmats for all types 

of transactions to be processed. Also helpful is a 

preliminary knowledge of system objectives and 

operating procedures obtained by reviewing and 

analyzing system flowcharts, operating instructions, 

and other documentation. This knowledge can alert 

the auditor to possible system weaknesses for which 

1 unique test transactions should be designed. 

‘The auditor should not overlook using test decks 

developed by operating personnel. 

often used for “debugging” data processing programs 

during the development of computer systems, may 

fulfill the auditor’s requirements with only minor 

alteration. Before using an agency’s test deck, 

however, the atiditor should determine whether it 

includes tests for all conditions which should be 

tested, including those involving invalid data. If 

it does not, the auditor should add simulated 

transactions designed to test for those conditions. 

He may also wish to consider using one of various 

test data packages available commercially. 

These test decks, 

8 

To be ej 

actions havix 

input data--\ 

operations ar 

controls. 

Only one 

against each 1 

lated evaluat. 

suring that tc 

other test trr 

master record. 

’A master recoi 

data treated r 

system, a pay3 

tion on an inc 

status. ) Mast 

machine-read& 

during data pr 

collectively e 

payroll sys ten 

make up the pa 
To be effective, a test deck should use transactions having a wide range of valid and invalid 

input data--valid data for testing normal processing 

operations and invalid data for testing programed 

controls. 

.' 

Only one test transaction should be processed 

I 

against each master record. This permits an isolated evaluation of specific program controls by insuring that test results will not be influenced by 

other test transactions processed against the same 

master 'record 

'A master record is a collection of related items of 

data treated as a unit. (For example, in a payroll 

system, a payroll master record contains information on an individual employee's pay history and 

status.) Master records are permanent records, in 

machine-readable form, and are updated periodically 

during data processing runs. They are referred to 

collectively as the "master file." Thus, in a 

payroll system, the master records for all employees 

make up the payroll master file. 

9 
, 

! 10 

General t 

tested are dim 

Tests of norma 

To test a 

ately process 

dlude transact 

ample, in a pa 

transactions i 

overtime pay, 

(such as shift 

records for ne 

ing master rec 

Tests using in 

. Testing f 

programed coni 

Examples of te 

jected or "f 1z 

1. Entei 

char2 
General types of conditions which should be 

tested are discussed below. 

Tests of normally occurring transactions 

To test a computer system's ability to accurately process valid data, a test deck should include transactions that normally occur. For example, in a payroll system, normally occurring 

transactions include the calculation of regular pay, 

overtime pay, and some other type of premium pay 

(such as shift pay), as well as setting up master 

records for newly hired employees and updating existing master records for other employees. 

Tests using invalid data 

Testing for the existence.or effectiveness of 

programed controls requires using invalid data. 

- 

Examples of tests for causing invalid data to be rejected or "flagged" are: 

1. Entering alphabetic characters when numeric 

characters are expected and vice versa. 

11 
12 

4 

3 

2. Using inT 

numbers. 

3. Using inc 

specific I 

4. Entering n 

tive amoun 

5. Entering il 

which logic 

6. Entering a 

does not mai 

lished by 01 

ling tables, 

codes for em 

system are A 

entered woulc 

or C. Anothe 

amount which 

ling salary t, 

Entering trans 

will violate 1 
2. 

3. 

4. 

5. 

6. 

7. 

Using invalid account or identification 

numbers. 

Using incomplete or extraneous data in a 

specific data field or omitting it entirely. 

Entering negative amounts when only positive amounts are valid and vice versa. 

Entering illogical conditions in data fields 

which logically should be related. 

Entering a transaction code or amount that 

does not match the code or amount established by operating procedures or controlling tables. For example, if the valid 

codes for employee status in a payroll 

system are A, B, and C, the code to be 

entered would be something other than A, B, 

or C. Another example is entering a salary 

amount whic6 is incompatible with a controlling salary table. 

Entering transactions or conditions that 

will violate limits established by law or 

13 

L:. . - 4 
by standard operating procedures. 

ample, in a payroll system, is the entry 

An exof X + 2 dollars as an employee’s gross 

pay when X dollars is the maximum gross pay 

allowed by law for the highest grade. 

t Tests to violate 

i established edit checks 1 

i 1 From system documentation, the auditor should 

be able to determine what edit routines are included 

in the computer programs to be tested. He should 

then create’test transactions to violate these edits 

I 

to see whether they, in fact, exist. 

ENTERING TEST DATA 

After the types of test transactions have been 

determined, the test data should be put into correct 

entry form. If the auditor wishes to test controls 

over both input and computer processing, he should 

feed the data into the system on basic-source documents for the agency to convert into machinereadable form (on punched cards, paper tape, magnetic tape, etc.). If he is only testing computer 

14 

I 
15 
processing controls, he should enter the data in 

machine-readable form. 

ANALYZING PROCESSING RESULTS 

Before processing test data through the computer, the auditor must predetermine the correct 

result for each test transaction fur comparison 

with actual results. 

and predetermined results indicates a weakness in 

the system's automated controls, which should be 

compensated for by an alternative control in the 

manual part of the system. 

tor should determine the effect of the weakness on 

the accuracy of master file data and on the reliability of reports and other computer products. 

Any difference between actual 

If it is not, the audiEven if a weakness in automated controls is 

compensated for by an alternative manual control, 

the auditor should consider recommending replacement 

of the alternative control by an automated control. 

* 

Controls should be automated whenever practical to 

increase the speed of data processing, to avoid unnecessary personnel costs, and to reduce errors that 

commonly occur in manually performed.operations. 

16 

17 
17 
APPLYING TEST DECKS AGAINST PROGRAMS 

THAT UPDATE MASTER RECORDS 

There are two basic approaches to test programs 

for master records updating. In one approach, copies 

of actual master records and/or simulated master 

records are used to set up a separate master file for 

the test. In the other, special audit records, kept 

I in the agency's current master file, are used. 

USING COPIED AND/OR SIMULATED 

MASTER RECORDS TO SET UP 

A SEPARATE TEST FILE 

To use the first approach, the auditor must 

have a part of .the agency's master file copied to 

1 

A possible third approach for using master records. 

is to process test transactions against actual 

master records in the agency's current master file. 

In this approach, the auditor includes test data 

with "live" transactions and processes it against 

actual master records during a regular processing 

run. Complications inherent in this approach are 

that (1) tests processed with actual transactions 

against actual records must be carefully controlled 

to prevent undesired changes or results and (2) test 

data used to update actual master records must later 

be reversed out of the system, which is a timeconsuming process requiring the highest order of 

competence, coordination, and precision. We do not 

recommend this approach because of these complications and the substantial risk of inadvertent 

changes and distortions in agency records and reports. 

18 

create a test mi 

file, he select: 

then updates th 

valid data by u 

the transaction 

Master re 

preparing sourc 

the program the 

master file. I 

records are thc 

An advant 

they can be ta 

they eliminate 

agency records 

however, when 

creation can 2: 

pared to the I 

a part of the 

Often, tl 

test master f: 

'A computer c; 

actual recorc 
create a test master file. From a printout of this 

file, he selects records suitable for the test. He 

then updates the test file with both valid and invalid data by using the agency's programs to process 

the transactions making up the test deck. 

1 Master records can be simulated most easily by 

preparing source documents and processing them with 

the program the agency uses to add new records to its 

master file. Procedures for test decking simulated 

records are the same as those for copied records. 

An advantage of using simulated records is that 

they can be tailored for particular conditions and 

they eliminate the need to locate and copy suitable 

agency records. This advantage is usually offset, 

however, when many records are needed because their 

creation can be complex and time consuming when compared to the relatively simple procedure of copying 

a part of the agency's master file. 

Often, the .most practical approach is to use a 

test master file which is a combination of copied 

'A computer cannot distinguish simulated from 

actual records. 

19 
and simulated master records. In this approach, 

copied records are used whenever possible and simulated records are used only when necessary to test 

conditions not found in the copied records. 

By using copied and simulated master records 

in a separate test file, the auditor avoids the 

complications and dangers of running test data in a 

regular processing run against an agency's current 

master file. (These complications and dangers are 

discussed below.) A disadvantage of copied and 

simulated records is that computer programs must 

be loaded and equipment set up and operated for 

audit purposes only, thus involving additional cost. 

USING SPECIAL AUDIT RECORDS 

MAINTAINED IN THE CURRENT MASTER FILE 

Special records can be kept in the agency's 

current master file for audit purposes only. Using 

this approach, the auditor includes test data with 

"live" transactions and processes it against the 

master file durkng a regular processing cycle. The 

special audit records are easy to identify because 

20 

they are give1 

lated. For e: 

ences to none: 

processing, tl 

"live" activii 

centers. 

This appi 

grams and perj 

test data. SI 

mal operating 

cessed faster 

uses copied 01 

ate test file. 

The audit 

processing tes 

transactions n 

agency ' s mas tc 

sonnel conceil 

example, by cl 

ences to real 

thermore, thiz 

reports produc 

thus necessitz 
they are given references which show they are simulated. For example, the records may contain references to nonexistent cost centers; during normal 

processing, these records remain inactive because 

''live" activity does not affect fictitious cost 

centers. 

This approach makes it unnecessary to load programs and perform other setup work solely to process 

test data. Since a system can be tested under normal operating procedures, a test deck can be processed faster and at less cost than when the auditor 

uses copied or simulated master records in a separate test file. 

The auditor should recognize, however, that 

processing test transactions concurrently with "live" 

transactions may inadvertently change or distort the 

agency's master records. Also, data processing personnel conceivably could activate these records (for 

example, by changing fictitious cost center references to real ones) and use them fraudulently. Furthermore, this approach may distort management 

reports produced by the normal processing cycle, 

thus necessitating clerical adjustments to correct 

* 

21 
the reports for the presence of test data. Finally, 

data processing personnel may object to having these 

audit records "clutter" their master file. Therefore, 

these tests must be carefully controlled. 

CONCLUSION 

The auditor must justify either (1) the risk of 

using actual master records or special audit records 

in the current master file or (2) the cost of having 

additional runs of computer programs being tested. 

Processing test data concurrently with "live" data 

to update current master records--which could be 

inadvertently altered or destroyed during the test-- 

is not recommended. 

simulated master records in a separate test file,, 

which does-not entail testing as a part of a regular processing run, is preferred. 

The use of copied and/or 

22 

su 

DES 

- 

- 

In design 

tor should: 

1, Detei 

inch 

2. Dete: 

be u: 

3. Obta 

Prep 

proc 

4. Prin 

recc 

I 

'Assuming the 

and/or s imu': 

master recoi 
SUMMARY OF SUGGESTED STEPS IN 

DESIGNING AND USING A TEST DECK 

In designing and using a test deck, the auditor should: 

1. Determine the types of transactions to be 

included in the test deck (see pp. 8 to 17). 

2. Determine the types of master records to 

be used (see pp. 18 to 22). 

3. Obtain copies of master records and/or 

prepare simulated master records for 

processing with the test transactions. 1 

4. Print out the contents of all such master 

records before the test. 

'Assuming the auditor has decided to use copied 

and/or simulated master records rather than "live" 

master records. 

23 
.- 

5. Predetermine the correct end result for 

each test transaction for comparison with 

actual processing results. (Appendix I 

shows how this was performed in two payroll system reviews. ) 

6. Verify that the programs used for processing the test transactions are the s&e as 

those used for normal payroll processing. 

7. Ascertain that any changes to these programs during the review have been documented and that the changes have been 

tested and approved by the agency, 1 

8. Arrange with data processing personnel for 

processing test transactions and producing 

output in a useful form. 

9. Print out the contents of all master records used in the test and compare with the 

'The auditor should be aware that agency employees 

can change computer programs by removing fraudulent or irregular routines. 

24 

pret 

whet 

pect 

10. Dete 

mate 

mast 

(see 

'The auditor rn; 

tion retrieva: 

the master re< 

identify all L 
predetermined results (see #5) to see 

whether the programs performed as expected. I 

10. Determine what impact weaknesses in automated controls have on the accuracy of 

master file data and computer output 

(see p. 16). 

'The auditor may wish to use a computerized information retrieval and analysis routine to compare 

the master records before and after the test to 

identify all changes made.. 

25 
APPENDIX I 

HOW TEST DECKS WERE DESIGNED AND USED 

IN TWO REVIEWS 

OF AUTOMATED PAYROLL SYSTEMS 

In making two recent reviews of automated 

civilian payroll systems, we used test decks to test 

the agencies' computer programs for processing pay 

and leave data. 

We first reviewed all available documentation 

for the manual and automated parts of each system. 

To understand the manual operations, we interviewed 

payro1.l supervisors and clerks, reviewed laws and 

regulations relating to pay and .leave, and familiarized ourselves with standard payroll operating procedures. For the automated part of each system, we 

interviewed system designers and programers and reviewed system and program documentation and operating procedures. 

After acquiring a working knowledge of each 

system, we decided to test computer programs used to 

update payroll master records and those used to calculate biweekly pay and leave entitlements, 

we were concerned primarily with these particular 

programs, we decided that other programs used in the 

Although 

26 

normal biweekl 

programs for p 

leave records, 

be tested to E 

We then c 

and leave trar 

internal cont.: 

and regulatioi 

operating pros 

actions made 

These transac 

dures and reg 

effectiveness 

tion's payrol 

for each mas1 

The besmaster recori 

to use copie 

with simulat 

not found in 

Accord j 

agency's pal 
APPENDIX I 

normal biweekly payroll processing cycle (such as 

programs for producing pay and leave history reports, 

leave records, and savings bond reports) should also 

be tested to see how they would handle test data. 

We then designed a test deck of simulated pay 

and leave transactions to test the effectiveness of 

internal controls, compliance with applicable laws 

and regulations, and the adequacy of standard payroll 

operating procedures. The test deck included transactions made up of both "valid" and "invalid" data. 

These transactions were based on specified procedures and regulations and were designed to check the 

effectiveness of internal controls in each -installation's payroll processing. 

for each master record chosen. 

We used one transaction 

The best method of obtaining suitable payroll 

master re-cords for out test, we decided, would be 

to use copies of actual master records, supplemented 

with simulated records tailored for test conditions 

not found in the copied records. 

Accordingly, we obtained a duplicate of each 

agency's payroll master file and had a section of it 
APPENDIX I 

printed in readable copy. From this printout, we 

selected a specific master record to go with each 

test transaction. When none of the copied records 

appearing on the printout fitted the specifics of a 

particular transaction, we made up a simulated 

master record by preparing source documents and 

processing them with the program used by each installation to add records for new employees to its 

master file, We then added the simulated records to 

the copied records to create our test master file. 

We next prepared working papers on which were 

entered, for each test transaction, the control 

number assigned to the transaction, the type of input document to be used, and the nature and purpose 

of the test. We predetermined the correct end results for all test transactions and recorded these 

results in our working papers for comparison with 

actual results. 

- 

With some help from payroll office personnel, 

we next coded the test transactions mto source 

documents. The data was then keypunched into punch d 

cards and key verified, 

data against actual agency payroll programs and 

We then processed the test 

_. .*. -- 

28 

compared the te 

results to see 

We found b 

several invalid 

been rejected o 

trols. Alterna 

nonexistent or 

they could be b 

fraud, neglect, 

mended that the 

strengthened to 

the Government 
APPENDIX I 

compared the test results with the predetermined 

results to see whether there were any differences. 

We found both systems accepted and processed 

several invalid test transactions that should have 

been rejected or flagged by programed computer controls. Alternative manual controls were either 

nonexistent or less than fully effective because 

they could be bypassed or compromised through 

fraud, neglect, or inadvertent error. We recommended that the systems' automated controls be 

strengthened to insure accurate payrolls and protect 

the Government from improper payments, 

, 

29 
APPENDIX I1 

TYPICAL PAYROLL TRANSACTIONS TO BE 

INCLUDED IN A TEST DECK 

Nature of test Purpose or explanation 

transaction of test transaction 

1. Leave a mandatory To determine whether th'e 

field blank on a 

new employee's . record with essential data 

master record. missing. If missing data 

system will accept a master 

will cause an incorrect pay- 

.merit, the master record 

should be rejected with 

appropriate warning; if 

missing data is for administrative purposes only, the 

condition should be flagged 

by an error .message. 

. 

. 

30 

How a system with e 

Rej 

Print CE 

error ci 

Reject message 2 

X 
APPENDIX I1 

1 

i 

I 

! f 

1 

i 

i 

i 

I 

i 

i 

i 

i 

I 

I 

I 

I 

I 

How a system with effective controls will handle the transaction 

Automat- AutomatReject in Cut back ically ically 

Print certain to Process compute adjust 

error circum- allowable without correct leave 

Reject message stances maximum cutback amount records 

X X 

31 
APPENDIX I1 

2. 

Nature of test 

transaction 

Enter erroneous 

codes, such as 

charity, life insurance, union 

dues, marital 

status, etc, 

(Note--one erroneous code per 

master record. ) 

3. Enter an invalid 

annual leave category - 

Purpose or explanation 

of test transaction 

To determine whether the 

system will accept invalid 

data into employees' master 

records. The program should 

print error messages to 

identify invalid data and 

reject further processing 

of such transactions, 

To determine whether the 

system will accept an invalid annual leave category. 

Federal regulations have 

established annual leave 

categories as 4, 6, or 8 

depending on the amount of 

creditable service, 

32 

How a system wii 

Print 

error 

Reject message 

X 

X X 
X 

APPENDIX I1 

How a system with effective controls will handle the transaction 

Automat- AutomatReject in Cut back ically ically 

Print certain to Process compute adjust 

error circum- allowable without correct leave 

Reject message stances maximum cutback amount records 

X X 

X 
1 

+ 

-I 

i 

1 

! 

I i 

i 

I 

i. 

f 

* 

I 

I 

I 

i 

I 

:I ! 

1 f 

I 

! 

i 

f 

I 

APPENDIX I1 

Nature of test Purpose or explanation 

transaction of test transaction 

4. Change a field in To determine whether it is 

an inactive master possible to change fields 

record. in inactive master records 

and whether adequate controls exist over such 

changes. Processing of inactive records should be 

separated from the normal 

processing of active records to eliminate the possibility of unearned salary 

payments or the manipulation 

of records for persons who 

are not in a pay status. 

How a system with 

R 

Print 

error 

Reject message - 

34 I 

X X 

c 

c 

-? 

:* 
\ APPENDIX I1 

How a system with effective controls will handle the transaction 

Automat- AutomatReject in Cut back ically ically 

Print certain to Process compute adjust 

error circum- allowable without correct leave . 

Reject message stances maximum cutback amount records 

X X 

t 

/ 35 
APPENDIX I1 

JL 

Nature of test Purpose or explanation 

transaction of test transaction 

How a system with e 

Re j 

Print ce 

error ci 

Reject message 

X X 

5. Change an employee's To determine whether the 

annual leave cate- system will reject invalid 

gory before it is updates. The annual leave 

due to be changed. category is based on the 

amount of creditable service an employee has, computed from the employee's 

service computation date. 

Employees with less than 

3 years of service are in 

category 4; employees with 

3 to 15 years of service 

are in category 6; employees with more than 15 

years of service are in 

category 8. The program 

should reject any attempt 

to change a leave category 

before it is due to be 

changed. 

36 
APPENDIX I1 

How a system with effective controls will handle the transaction 

Automat- AutomatReject in Cut back ically ically 

Print certain to Process compute adjust. 

error circum- allowable without correct leave 

Reject message stances maximum cutback amount records 

X X 

37 

.~ . .- -. . 
APPENDIX I1 

Nature of test 

transaction 

6, Promote a general 

schedule (GS) employee above 

grade 5 before 

1 year in grade 

has passed. 

7. Give a GS employee 

a within-grade 

salary increase 

before 1 year in 

grade has passed. 

Purpose or explanation 

of test transaction 

To determine whether the 

system rejects an invalid 

transaction. Federal regulations state that GS employees above grade 5 must 

be in grade at least 1 year 

before they can be promoted. 

To determine how the system 

handles this transaction, 

Federal regulations state 

that a GS employee must be 

in grade at least 1 year 

before being eligible for a 

within-grade salary increase. 

. The system should "flag" the 

transaction as being a quality step increase (which has 

the same effect as a withingrade increase but can occur 

without the employee's having 

been in grade for 1 year). 

38 --- 

5 2 

c 

i 

ci. 

How a system'with eff 

Rejec 

Print cert 

error circ 

Reject message stan 

c 

2- 

X X 

X 
APPENDIX I1 

How a systern'with effective controls will handle the transaction 

Automat- Automat- 7Z.w. . Reject in Cut back ically ically 

Print certain to Process compute adjust 

error circum- allowable without correct leave 

Reject message stances maximum cutback amount records 

X X 

X 

39 
APPENDIX I1 

How a system with . 

Nature of test 

transaction 

8. Change an employee's grade or 

annual salary so 

that the grade/ 

step and annual 

salary rats are 

incompatible. 

9. Change an em- . 

ployee's service 

computation date 

to indicate that 

leave category 

is due to change. 

Purpose or explanation 

of test transaction 

TO determine whether the 

system accepts incompatible 

data. The program should 

have salary and grade controls which will reject 

transactions of this type 

from further processing 

(except for payments under 

Re. 

Print ct 

error CI 

Reject message si 

X 

the Civil Service "retained 

rate" provision, which 

allows certain downgraded 

employees to retain their 

old salaries for a time). 

X 

To determine whether the 

annual leave category is 

correctly changed, with a 

message printed to indicate 

the change. If tile leave 

category is not automatically changed, a message 

should be printed. 

f 

i B r: :I_ 

i 

4'- 

1 

I' 
_; -

APPENDIX I1 

.t- How a system with effective controls will handle the transaction 

Automat- AutomatReject in Cut back ically ically 

Print certain to Process compute adjust 

error circum- allowable without correct leave 

Reject message stances maximum cutback amount records 

X X 

X 

41 

.. .. .... . . __ - - :----.- - ., .. ~ . - .si 
APPENDIX I1 

.L ! 

How a system with 

Nature of test 

transaction 

10. Pay an inactive 

employee. 

11. Pay. a nonexistent 

employe e 

I ! c 

12. Input two time and 

attendance cards 

for the same 

employee. 

Purpose or explanation 

of test transaction 

To determine whether the 

system will compute pay for 

an inactive employee (an 

Re 

Print c 

error c 

Reject message 2 ., 

employee who has been separated but whose record is 

maintained in the same 

master file used for active 

employees). 

To determine whether the 

system will compute pay for ! -i 

an employee with no record ii 

in the master file. 

To determine whether the 

system will compute pay 

X 

X 

twice for the same employee. 

X 

X 

42 
How a system with effective controls will handle the transaction 

Automat- Automat- 

! 

I. 

I. 

X X 

X X 
APPENDIX 11 

Nature of test Purpose or explanation 

transaction of test transaction 

13. Pay a GS employee To determine whether the 

for 80 hours work system rejects WB entitleon a second-shift ments for GS employees. 

entitlement for a 

wage board (WE) 

employee. 

14. Pay a GS employee Same as above. 

for 80 hours work 

on a third-shift 

entitlement for a 

WB employee.. 

L 

! 

. 

15. Pay a WB employee 

for 80 hours work 

To determine whether the 

system rejects GS entitleHOW a system with e 

Rej 

. Print ce 

error ci: 

Reject message st; 

X X 

X X 

on a nightdifferential 

entitlement for 

a GS employee. 

ments for WB employees. 

44 

X X 
.'- 

APPENDIX I1 

How a system with effective controls will handle the transaction 

Automat- AutomatReject in Cut back ically ically 

Print certain to Process compute adjust 

error circum- allowable without correct leave 

Reject message stances . maximum cutback amount records 

X X 

X 

X 

X 

x: 
APPENDIX I1 

16. 

17. 

18. 

19. 

Nature of test 

transaction 

Pay a WB employee 

for 20 hours of 

overtime. 

Pay a GS employee 

for 20 hours of 

night-differential 

Pay 

Pay a WB employee 

for 80 hours on 

second shift. 

Pay a WB employee 

for 80 hours on 

third shift. 

Purpose or explanation 

of test transaction 

To verify the accuracy of 

premium (overtime) pay 

computation. Overtime pay 

is 1-1/2 times regular pay. 

Same as above. 

Premium = 10 percent. 

Same as above. 

Premium = 7-1/2 percent. 

Same as above. 

Premium = 10 percent. 

How a system with e 

Rej, 

Print ce. 

error ci: 

Reject message 

I 

r ,. 

.. 
APPENDIX I1 

How a system with effective controls will handle the transaction 

Automat- AutomatReject in Cut back ically ically 

Print certain to Process compute adjust 

error circum- allowable without correct leave 

Reject message stances maximum cutback amount records 

X 

X 

X 

-- .- .. 
i 

I APPENDIX I1 

Nature of test 

transaction 

20; Pay a GS employee 

for 8 hours of 

holiday pay. 

21. Pay a WB employee 

€or 8 hours of 

holiday pay. 

22. Pay a GS employee 

for 8 -hours of 

Sunday pay (for 

Sunday work that 

is not overtime 

work). - 

23. Pay a WE! employee 

for 8 hours of 

Sunday pay. 

Purpose or explanation 

of test transaction 

Same as above. Holiday 

pay is double regular pay. 

Same as above. 

i 

I! 

Same as above. Sunday j 

premium is 25 percent of, 

regular pay if Sunday is 

a regularly scheduled 

workday. 

Same as above. 

48 . 

How a system with effecti 

Reject ir. 

Print certain 

error circumReject message stances 
APPENDIX I1 

How a system with effective controls will handle the transaction 

Automat- AutomatReject in Cut back ically ically 

Print certain to Process compute adjust 

error circum- allowable without correct leave 

Reject message stances maximum cutback amount records 

X 

X 

.. 

X 
APPENDIX I1 

Nature of test 

transaction 

24. Pay GS employees 

for 10 hours of 

environmental pay 

at the following 

premiums : .I a. 4% 

b. 8% 

c. 25% 

d. 50% 

25. Pay WB employees 

for 10 hours of 

environmental pay 

at the following * 

premiums : 

a*- 4% 

b. 8% 

c. 25% 

d. 50%' 

.. 

50 

Purpose or explanation 

of test transaction 

Same as above. 

Same as above. 

...- 

How a system with effective 

Reject in 

Print certain 

error circum- i 

Reject message stances - 
APPENDIX I1 

How a system with effective controls will handle the transaction 

Automat- AutomatReject in Cut back ically ically ~ 

Print certain to Process compute adjust 

error circum- allowaSle without correct leave 

Reject message stances maxim*m cutback amount records 

X 

X 

.- . 

51 
1 APPENDIX I1 

I 

Nature of test 

transaction 

26. Pay a GS-1, 2, 3, 

4, 5, 6, or 7 employee for 10 hours 

of overtime. 

27. Pay a GS-10, 11, 

12, or 13 employee 

for 10 hours of 

overtime. c 

Purpose or explanation 

of test transaction 

To verify accuracy of 

premium pay computation. 

For GS employees whose 

basic pay rate does not 

exceed the salary of a 

GS-10/1, the overtime rate 

is 1-1/2 times the basic 

pay rate. (FPM 550-5) 

Same as above. For a GS 

employee whose basic pay . 

rate is equal to or exceeds 

the rate of a GS-10/1, the 

overtime rate is 1-1/2 

times the hourly rate for 

a GS-10/’1. (FPM 550-5) 

52 

, _L. 

How a system with effect 

Reject i 

Print certaic 

error circumReject message stances 
-- 

APPENDIX I1 

How a system with effective controls will handle the transaction 

Automat- AutomatReject in Cut back ically ically 

Print certain to Process compute adjust 

error circum- allowable without correct leave 

Reject message stances maximum cutback amount records 

X 

X 

53 
APPENDIX I1 

Nature of test 

transaction 

28. Pay a GS-14 employee enough overtime pay to exceed 

the maximum salary 

limitation. 

29. Pay a GS-14 em- * 

ployee enough environmental pay to 

exceed the maximum 

salary limitation. 

Purpose or explanation 

of test transaction 

To test maximum salary limitation. Additional pay, 

such as overtime, nightdifferential, holiday, and 

Sunday pay, may be paid to 

the extent that it does not 

cause the aggregate pay for 

a biweekly period to exceed 

the rate of a GS-15/10. 

(FPM, 550.105) The program 

should cut back pay to this 

maximum. 

Same as above, Program 

should not cut back environmental pay because it is not 

subject to the maximum 

salary limitation. 

How a system with effecti 

Reject ir: 

Print certain 

error circumReject message stances 

X 

i 

54 
APPENDIX I1 

How a system with effective controls will handle the transaction 

Automat- AutomatReject in Cut back ically ically 

Print certain to Process compute adjust 

error circum- allowable without correct leave 

Reject message stances maximum cutback amount records 

X X 

X 
APPENDIX I1 

Nature of test Purpose or explanation 

transaction of test transaction 

30. Pay a WB employee Same as above. Program 

enough premium pay should not cut back pay 

to exceed the maxi- because WB employees have 

mum salary limita- no maximum salary limitation. tion. 

31. Pay a GS employee To determine whether the 

for 1 hour of holi- system will pay less than 

the 2-hour minimum of 

holiday pay. (FPM 990-1) 

32. Pay a WB employee Same as above. 

for 1 hour of holiday pay. 

* 

33. Pay a GS employee To determine whether the 

for 40 hours of 

Sunday pay. 

system limits Suiday pay to 

32 hours maximum allowed. 

(FPM 990-2) 

How a system with effect 

Reject 1 

Print certai~ 

error circumReject message stance. 

X 

x 

X 
APPENDIX I1 

How a system with effective controls will handle the transaction 

Automat- AutomatReject in Cut back ically ically 

Print certain to Process compute adjust 

error circum- allowable without correct leave 

Reject message stances maximum cutback amount records 

X 

X 

X 

X 

X 

X 
APPENDIX I1 

Nature of test 

transaction 

34. Pay a WB employee 

for 80 hours on 

second shift and 

10 hours for overtime into the third 

shift . 

Purpose or explanation 

of test transaction 

To verify the accuracy of 

premium pay. Federal regulations state that overtime 

pay for an employee regularly working the second or 

third shift will be computed 

at 1-1/2 times the second or 

third shift rate, repective1.y. (FPM 532-1) 

35. Pay a WB employee Same as above. 

for 80 hours on 

third shift and 10 

hours for overtime 

into the first 

shift. 

58 

Reject i 

Print certain 

error circmReject message stances 

i 
‘U - 

.me 

- 

or 

uted 

3. or 

APPENDIX I1 

HH 

Automat- AutomatReject in Cut back ically ically 

Print certain to Process compute adjust 

error circum- allowable without correct leave 

Reject message stances maximum . cutback amount records 

X 

X 
APPENDIX 11 

Nature of test 

transaction 

36. Charge a full-time 

employee for 80 

hours of leave 

without pay 

(LWOP) . 

37. .Charge a full-time 

employee for more 

annual leave than 

the employee has. 

Purpose or explanation 

of test transaction 

To determine whether sick 

and annual leave will accrue 

when a full-time employee 

charges 80 hours LWOP. The 

sick leave credit should be 

reduced by 4 hours and the 

annual leave credit should 

be reduced by 4, 6, or 8 

hours, depending on the 

annual leave category. 

To determine whether excess, annual leave is 

charged to LWOP. (The 

system should automatically 

reduce employee's pay for 

LWOP . ) 

- 

60 

How a system with effectiv 

Reject in 

Print certain 

error circumReject message stances 

X 
-ue 

APPENDIX I1 

How a system with effective controls will handle the transaction 

Automat- AutomatReject in Cut back ically ically 

Print certain to Process compute adjust 

error circum- allowable without correct leave 

Reject message stances maximum cutback amount records 

X 

X X 

. 

X 

61 
APPENDIX I1 

Nature of test 

transaction 

38. Charge a full-time 

employee for more 

sick leave than 

the ,,iployee has. 

39. Charge a full-time 

employee for 99 

hours of annual 

leave (19 hours 

more than a regylar biweekly 

period). 

40, Charge a full-time 

employee for 99 

hours of sick leave. 

Purpose or explanation 

of test transaction 

To determine whether excess 

sick leave is charged to 

annual leave or LWOP. (The 

system should automatically 

adjust leave records and 

reduce pay for LWOP, if 

required.) 

To determine whether the 

system wili cut back to the 

maximum of 80 hours for 

regular pay in a pay 

period. 

Same as above. 

62 

How a system with effec 

Reject 

Print certai 

error circurr 

Reject message stance 

X 

X 

X 
. -1- 

APPENDIX I1 

How a system with effective controls will handle the transaction 

Automat- AutomatReject in Cut back ically ically 

Print certain to Process compute adjust 

error circum- allowable without correct leave 

Reject message stances maximum cutback amount records 

X X X 

X 

X 

x 

X 

63 
APPENDIX I1 

Nature of test 

transaction 

41. Charge a full-time 

employee for 80 

hours of regular 

pay and 80 hours of 

annual leave in the 

same pay period. 

42. Charge a full-time 

employee for enough 

hours of military 

leave to exceed 

120 hours total. 

Purpose or explanation 

of test transaction 

Same as above. Total hours 

of work and leave cannot 

exceed 80 in a pay period. 

To determine whether the 

system flags military leave 

in'excess of 120 hours. 

Federal regulations state 

that an employee cannot 

charge more than 120 hours 

to military leave in a pay 

year. Because there are 

certain exceptions (such as 

duty in the District of 

Columbia Nationai Guard) 

which permit military leave 

to exceed 120 hours, the 

64 

How a system with effective c( 

Reject in Cu 

Print certain 

error circum- all 

Reject message stances ma 

X X 
.- S 

.s 

APPENDIX I1 

How a system with effective Controls will handle the transaction 

Automat- AutomatReject in Cut back ically ically 

Print certain to Process compute adjust 

error circum- allowable without correct leave 

Reject message stances maximum cutback amount records 

X X 

65 
APPENDIX I1 

Nature of test 

transaction 

42. cont'd. 

Purpose or explanation 

of test transaction 

system should alert payroll 

clerks to the excess and 

should not reject or cut 

back the transaction. 

43. Make a lump-sum To determine whether the 

annual leave pay- system appropriately exment to a separ- cludes excess annual leave 

ated employee in in a lump-sum leave payment. 

excess of annual 

leave balance. 

cHow a system with effect: 

Reject i: 

Print certain 

error circumReject message stances 

X 
mation 

ztion 

-t payroll 

!ss and 

or cut 

on. 

er the 

ly exsl leave 

2 payment. 

APPENDIX I1 

How a system with effective controls will handle the transaction 

Automat- AutomatReject in Cut back ically ically 

Print certain to Process compute adjust 

error circum- allowable without correct leave 

Reject message stances maximum cutback amount records 

X X 

67 
APPENDIX I1 

Nature of test 

transaction 

44. Pay a GS part-time 

employee for 32 

hours of regular 

Pay 

Purpose or explanation 

of test transaction 

To determine whether the 

system correctly accrues 

annual and sick leave for 

part-time employees. For 

each 20 hours worked, a parttime employee receives 1 hour 

of sick leave. If in leave 

category 4, an employee needs 

20 hours of work to earn 1 

hour of annual leave; if in ~ 

leave category 6, the employee needs 15 hours worked 

to earn 1 hour of annual 

leave: and if in leave category 8, the employee needs 

10 hours worked to earn 1 

hour of annual leave. 

How a system with effecti 

Reject ir 

Print certain 

error circumReject message stances 
APPENDIX If 

HOW a system with effective controls will handle the transaction 

Automat- AutomatReject in Cut back ically ically 

Print certain to Process compute adjust 

error circum- allowable without correct leave 

Reject message stances maximum cutback amount records 

X 

I i 69 
... I- ..--..-.=A .. . - . . . 

PPENDIX I1 

Nature of test Purpose or explanation 

transaction of test transaction 

5. Make a lump-sum To determine whether the 

annual leave payment to an active 

employee. active employee. These payments should be made only to 

separated employees. 

system will make a lump-sum 

annual leave payment to an 

1 

How a system with effective 

Reject in 

Print certain 

error circm- e 

Reject message stances - 

X X 
71