© 2003 McGraw-Hill Australia Pty Ltd, PPTs t/a Accounting Information & Reporting Systems by A. Aseervatham and D. Anandarajah. Slides prepared by Kaye Watson. 8-1 chapter 8 Testing and documenting systems Learning objectives –To understand the need for testing a computer system in an operational environment. –To discover the different types of testing. –To learn about documenting a system before implementation and training. –To learn about the different media used for documentation. –To understand why it is necessary to consult users to ensure acceptability of documentation. –To learn about reviewing and updating documentation to ensure currency and accuracy.

© 2003 McGraw-Hill Australia Pty Ltd, PPTs t/a Accounting Information & Reporting Systems by A. Aseervatham and D. Anandarajah. Slides prepared by Kaye Watson. 8-2 key terms acceptance testing capacity testing prototyping rapid application development system testing unit testing

© 2003 McGraw-Hill Australia Pty Ltd, PPTs t/a Accounting Information & Reporting Systems by A. Aseervatham and D. Anandarajah. Slides prepared by Kaye Watson. 8-3 Acceptance testing Testing by users before a system goes live to prevent expensive corrections or reconstruction Rapid application performance testing (RAPT): –allows developers and users to test system modules as they are developed Prototyping: –when a working model of a system is built for testing purposes

© 2003 McGraw-Hill Australia Pty Ltd, PPTs t/a Accounting Information & Reporting Systems by A. Aseervatham and D. Anandarajah. Slides prepared by Kaye Watson. 8-4 Acceptance testing Unit testing: –testing each stage of in-house software packages as they are developed System testing: –primarily carried out by programmers in the development environment Operational environment testing: –‘user acceptance testing’ generally done just before the processing begins but after the system is in the real-life environment

© 2003 McGraw-Hill Australia Pty Ltd, PPTs t/a Accounting Information & Reporting Systems by A. Aseervatham and D. Anandarajah. Slides prepared by Kaye Watson. 8-5Documentation Documents created after systems are tested and accepted can be categorised into: –Program documentation shows the coding relationships and comments made by programmers –System documentation used to detail the system’s design specifications, internal workings and functionality

© 2003 McGraw-Hill Australia Pty Ltd, PPTs t/a Accounting Information & Reporting Systems by A. Aseervatham and D. Anandarajah. Slides prepared by Kaye Watson. 8-6 Documentation (cont.) –User documentation documentation that users can refer to for information about procedures (e.g. ‘wizards’ and cue cards) –Operations documentation operator’s manual; mainly applies to mainframe computer systems

© 2003 McGraw-Hill Australia Pty Ltd, PPTs t/a Accounting Information & Reporting Systems by A. Aseervatham and D. Anandarajah. Slides prepared by Kaye Watson. 8-7 User satisfaction with documentation User documentation should cater for all types of users and consideration should be given to: –the level of language (should be simple and non- technical) –the learning capacity of users –the fact that the level of experience for users will differ –the fact that work styles and habits of users will differ (e.g. some will prefer to use a mouse, others will prefer keystroke commands)

© 2003 McGraw-Hill Australia Pty Ltd, PPTs t/a Accounting Information & Reporting Systems by A. Aseervatham and D. Anandarajah. Slides prepared by Kaye Watson. 8-8 Maintenance of documentation Documentation should be easily accessible to users Needs to be kept updated and current A register for paper documentation should be maintained to identify the location of copies and ensure changes are made to all copies