Spreadsheet bibliography

Title Compliance-appropriate spreadsheet testing
Authors Raymond R. Panko
Year 2006
Type Proceedings
Publication 12th Americas Conference on Information Systems
Series August, Paper 130, pages 980-986
Abstract

Sarbanes–Oxley compliance requirements have forced firms to look at their use of spreadsheets in financial reporting. They are finding that they have many spreadsheets and that testing and other formal development disciplines are rare.

The literature on spreadsheet errors has shown that without strong controls, most spreadsheets will have material errors; this means that firms that use uncontrolled spreadsheets cannot plausibly claim to be in compliance with Sarbanes–Oxley.

This paper looks at a promising control discipline for bringing spreadsheets into Sarbanes–Oxley compliance, namely logic inspection testing following the traditional Fagan (1976) methodology created for software testing.

Full version Available
Sample
The Fagan method

The basic methodology of software code inspection was laid down by Fagan (1976), and it still is the main methodology for code inspection today. In this methodology, there are four phases:

  • Initial meeting. The process begins with an introductory meeting for the team. At this meeting, the code developer describes the requirements of the module and walks the team through the code.
  • Individual inspection. After the meeting, the team members inspect the module individually, looking for errors. There normally is a time limit for this. Often, this time limit is about two hours.
  • Concluding meeting. After the team members have finished their individual inspections, the team holds a concluding meeting at which the team members go over the errors discovered by the individual members and perhaps look for additional errors. They attempt to develop a consensus about which defect reports are real and to rate the severity of defects. They do not attempt to fix the errors, however.
  • Reporting. One tenet of code inspection is that results should be summarized and reported. Reporting results is critical for learning. Most of what we know about software error rates comes from code inspection reports.