Previous Table of Contents Next


Once the input and output are known, the required processing can be determined. Cross-referencing input fields to output fields indicates one of the following processing conditions:

  There is no input field for a given output field; hence, the required information cannot be produced.
  There is a one-to-one relationship between input and output. In this case, data from an input record need only be moved to an output file so that processing is simply a matter of moving data.
  The desired information must be calculated from the input. Totaling, editing, calculations, or comparisons based on two or more input fields or records may be required.

The following factors must be taken into account during the development of the test tools.

  If the sequence of input is not the sequence desired for output, the file must be sorted.
  If the test tool cannot perform the desired processing, another test tool may be required, necessitating the specification of more than one test tool to accomplish one test condition. Other possibilities are to change the processing specifications or to perform the work formed in two or more audit analyses.
  If the data file is not in a format that can be read by the test tool, the data may have to be reformatted. Some audit software packages, for example, cannot read from database systems, and a special program must be written to convert these records into a sequential file that can be read by the audit software.

The successful completion of this task requires that the selected tool be able to meet the specifications. In addition, the IT auditor must check for errors in logic that would prevent producing the desired results and incomplete logic that would preclude creation of the test tool.

VERIFY FILE INTEGRITY

Because of the real risk of producing invalid conclusions, it is essential that the IT auditor not develop opinions or recommendations based on data analysis from a file whose integrity cannot be verified. The objective of this task is to prove the integrity of the file from which data is obtained, allowing its use as a basis for an opinion. (If the data is to be used for background purposes only, this task can be omitted.) Verifying the integrity of a computer file means proving that the totality of data on the file is correct. In an accounts receivable file, for example, this involves reconciling the totals of the records on the file with the amount of accounts receivable on the organization’s financial statements. This is accomplished by adding all the open items on the accounts receivable file and comparing the total with that on the financial statement. If the two are equal or reconcilable, the integrity of the file is proved, and the file can then be used to extract or analyze data for audit purposes.

Key Field Proof. With this method, a field, usually the control field, is totaled and compared with an independent source. (The accounts receivable file verification example used the key field proof method.)

Completeness Proof. This method counts some item on the file and verifies it against a count of that field. A simplified example would be verifying the completeness of a customer file by counting the number of customers on the file and comparing it with the total number of customers the organization believes it has. Other completeness proof methods include:

  Proof of pointers. The completeness of pointers in a database or random-type file is verified.
  Check digits. These are used to verify that the arrangement of data within a field is correct (can also be used for data within the record).
  Hash total. Data not otherwise used for control purposes (e.g., part numbers or invoice numbers) is counted to verify that the data is complete (or not rearranged). For example, the accounts receivable file might be complete based on a key field, but a new customer’s name might have been substituted. The hash total would disclose a change in the structure of the records and thus indicate a completeness problem.

Simple Accounting Proof. A simple accounting proof is a reconciliation of processing over a period of time. It involves starting with a verified previous balance and substantiating additions and deletions to the file. The balance produced by the simple accounting proof is then compared with the balance on the computer file to verify its accuracy. In completing this task, the IT auditor must be careful not to lose control of the file after its integrity has been proved but before it has been analyzed. It is also possible that the total value of the file is correct but the information in the file is incorrect; the IT auditor must confirm that this is not the case.

EVALUATE THE CORRECTNESS OF THE TEST PROCESS

Almost all auditing standards include a statement like “the systems are to be properly supervised.” This statement places the responsibility on the IT auditor or audit organization for ensuring that staff members receive effective on-the-job training and sufficient guidance to produce high-quality work. Assistants must understand their assigned tasks, conform to auditing standards, and follow the audit programs as appropriate. The objective of this task, therefore, is to exercise supervisory responsibility over and provide guidance to an assistant-the computer audit program. To do so, the IT auditor must review the program to confirm that it functions properly and will produce the desired results.

Each computer program should be tested in terms of both structure and function. Structural testing determines whether the program is structurally correct and can work in an operating environment; that is, it confirms that the tables are large enough, the instructions are used correctly, and the program has been configured for the hardware on which it will run. Functional testing is designed to ensure that the system does what it is supposed to do. Although structural problems affect function, they may not do so during the test, and the program may perform properly when processing only one or two records. When several thousand records are processed, however, the internal tables may not be large enough to accommodate the necessary volumes.

Both static and dynamic tests should be used to verify the structural and functional aspects of the program. In a static test, the IT auditor analyzes the program in a nonoperational mode to determine whether it is performing correctly. In a dynamic test, test transactions are prepared or a limited set of live transactions are used to verify that the program works in an operational mode. The static test should be performed first, followed by the dynamic test.

Although it is generally advisable to prepare special test transactions, it may be possible to use a subset of the production file to test the program. Some generalized audit software has the capability to select a predetermined number of live transactions from a production file for test purposes. When conducting these tests, the IT auditor must understand that an undetected bug or untested but important logic path could cause the program to function incorrectly in a production environment. The IT auditor must also be aware of the possibility that the program might reach an untested limit and either terminate abnormally or produce incorrect results.


Previous Table of Contents Next