IDW PS 880

from Wikipedia, the free encyclopedia

The IDW PS 880   The testing of software products is a testing standard (PS) of the Institute of Auditors (IDW). The auditing standard was approved by the Main Technical Committee (HFA) on March 11, 2010.

General

The auditing standard supports auditors in auditing and issuing certificates for software products. This IDW test standard replaces the IDW PS 880 i. d. F. of June 25, 1999 and takes into account the requirements of ISAE 3000 "Assurance Engagements Other Than Audits or Reviews of Historical Financial Information" for audits that are aimed at making audit statements with sufficient certainty (reasonable level of assurance). The procedure for testing software products follows the systematic approach for system testing when using information technology (IT), as laid down in IDW PS 330 . The regulations of the IDW RS FAIT 1 apply to the concept of information technology and the compliance and security requirements when using IT . In addition, the IDW auditing standard deals with the utilization of the results of the testing of software products as part of a final audit at the software user to assess the correctness and security of bookkeeping. In this respect, this IDW test standard specifies the considerations contained in IDW PS 320 and IDW PS 322 on the use of test results from third parties.

Addressee groups

The IDW PS 880 is aimed at software manufacturers of all kinds.

object

The subject of software tests are software products, regardless of their implementation and going live with the software user. According to IDW RS FAIT 1 , Item 12, software products are IT applications created in-house as well as IT applications obtained from third parties. They are used either independently or in conjunction with other software products. Software tests are aimed at both standard software products from a software manufacturer and individual software solutions. Standard software products are designed for a wide range of uses and can usually be adapted to the needs of different companies by means of parameterization. Individual software solutions, on the other hand, are specially developed for the needs of a software user. Depending on their functional scope and area of ​​application, software products can be relevant to accounting or control and monitoring in the company to different degrees. IT applications that are more closely related to accounting are used for IT-supported processing of accounting-relevant business processes. In addition to financial accounting programs, this includes in particular ERP systems that cover other areas of activity in addition to financial accounting, such as asset accounting, materials management, purchasing, sales and human resources management. Software products that are used for control and monitoring in the company have a rather broader relation to accounting. Typical examples are data warehouse systems, payment transaction systems, consumption calculation programs or IT applications for risk control at banks and insurance companies. The subject of the examination can be the software products as a whole, individual modules or individual functions. Examples of checking individual functions are booking interfaces in IT applications for technical consumption measurement or document processing in an electronic invoicing system . Software tests include the assessment of the program functions necessary for the area of ​​responsibility of the software products. Program functions in the sense of this IDW audit standard are composed of the processing functions and the program-internal control system. The program-internal control system includes in particular the input, processing and output controls and the programmed sequence control (program sequences and programmed rules for workflow control) including the program-internal access protection system.

Procedure as part of an audit

1. Recording of the software product to be tested and the software development environment as well as the completeness and currency of the process documentation,

2. Assessment of the software development process including the software maintenance, test and release process,

3. Examination of the appropriateness of the program functions necessary for the area of ​​responsibility of the software product (build-up examination) and the informative value of the relevant procedural documentation as well

4. the examination of the appropriate technical implementation of the program functions judged to be appropriate (functional test).

5. The software development process is then to be assessed whether

  • from the structural and procedural regulations for software development including quality assurance measures and
  • from the IT infrastructure used for software development

Risks for a proper implementation of the processing functions to be checked arise.

As part of the examination of the appropriateness of the program functions (structural examination), it must be assessed on the basis of the process documentation whether the requirements relevant to the area of ​​responsibility of the software products have been properly defined by the software manufacturer. This also requires that an appropriate internal program control system is provided and meaningful procedural documentation is available. On the basis of test cases, the technical implementation of the program functions assessed as appropriate is checked (functional test). Depending on the results of the risk assessment of the software development process, the auditor will use the software manufacturer's test cases, which are supplemented by their own random test cases.

The determination of the test program and the scope of one's own test cases is based in particular on the assessment of the documentation and test procedures used, as well as the test cases carried out and documented by the software manufacturer and their results.

Goal of the software test

The aim of the software test is to assess with sufficient certainty whether the software product, when used properly, enables it to meet the criteria that were agreed as a yardstick for assessing the functional requirements of the software products in the test order. Generally accessible criteria for a software test in accordance with IDW PS 880 are, in particular, legal and regulatory requirements as well as other requirements relating to the software's area of ​​responsibility. In the case of software products related to accounting or the internal control or risk management system, the following are particularly applicable:

  • The principles of proper accounting and the associated requirements for the correctness and security of accounting-related program functions and
  • regulatory provisions on accounting and the internal control system as well as risk management (e.g. Section 25a KWG).

criteria

If the software product has no relation to accounting or the internal control or risk management system, the following criteria come into particular consideration:

  • task-specific norms and standards or
  • specific branch and industry standards related to IT.

With these criteria, it can regularly be assumed that they are suitable for assessing software products, insofar as they are relevant to the field of application of the software products. In contrast to this, criteria developed by the software manufacturer themselves have not gone through a formal formulation, coordination and publication process. For this reason, criteria developed by the software manufacturer must always be checked as to whether they meet the requirements of this IDW test standard. Criteria developed by the software manufacturer itself can only be used as an assessment standard for a software test in accordance with IDW PS 880 if they are suitable for this. Suitable criteria within the meaning of this IDW test standard must have the following properties:

  • Relevance : Criteria must be decisive for the assessment of the software product and for decision-making.
  • Completeness : Criteria are complete if none of the aspects essential for assessing the software product and for decision-making have been excluded.
  • Reliability : Reliability means that the criteria allow a consistent and comprehensible assessment of the software product.
  • Neutrality : Criteria are neutral if they ensure an objective assessment of the software product.
  • Comprehensibility : Criteria are understandable as long as they allow clear conclusions and thus avoid misinterpretations.

Examples of criteria developed by the software manufacturer itself are project and programming guidelines that are used for the external design of dialog masks ( graphical user interface (GUI) ) and workflow controls. GUI specifications represent a suitable internal criterion, for example, since from the point of view of a potential user, the uniformity and logic of the user interface are essential for the usability of the software products and can thus influence the purchase decision (relevance of the criterion).

The property completeness of the criterion would be given in this example if there are specifications for the formal design for all design elements of a screen mask, including color design, placement, recurring functions, specifications for field placement and design, which are to be used without exception for all screen masks.

The requirements for reliability, neutrality and comprehensibility of the criterion are met if the specifications are specified in such a way that deviations from the specifications can be measured and objectively determined and the rules for designing the graphical user interface do not allow any room for interpretation.

Individual evidence

  1. ↑ IDW PS 880. Retrieved July 26, 2019 .