Artikel
Testate: Nutzen oder Augenwischerei
Wenn es um die Prüfung von Software und deren Einsatz durch externe oder interne Revisoren geht, wird oft die Frage nach einem die Software-Qualität bestätigenden Gütemaß gestellt. Sowohl bei bereits im Unternehmen eingesetzter und freigegebener als auch bei neu zu beschaffender Software wird in der Praxis häufig Wert auf ein Testat gelegt.
Der folgende Artikel befaßt sich mit den Bedingungen für eine Testatvergabe sowie den Möglichkeiten und kritischen Aspekten, die sich durch den Einsatz testierter Software ergeben.
Als Gütesiegel für Softwareprodukte sind unter anderem die Prüfungen nach der DIN ISO / IEC 12119 oder die Prüfung aus dem Bereich der Vergabe der ISO9000 Zertifizierung bekannt. Diese werden beispielsweise auch vom TÜV Rheinland durchgeführt und führen zu dem sogenannten RAL-Zeichen. Derartige Prüfungen und Qualitätssiegel lassen sich auf fast alle Software-Bereiche anwenden und zielen auf die Software selbst sowie auf die Produktbeschreibung ab.
Aus Sicht der internen und externen Revisoren sind diese Zertifizierungen für die Qualitätsbestimmung sowie als Grundlage der eigenen Prüfung weitgehend ohne Bedeutung, weil diese Prüfungen auf revisionsfremde Fragestellungen ausgerichtet sind.
Demgegenüber steht die testierte Software.
Diese von Wirtschaftsprüfungsgesellschaften und Wirtschaftsprüfern für rechnungslegungsnahe Software vergebene Bestätigung bezieht sich nach herrschender Meinung immer auf die mögliche Einhaltung der GoB *1 sowie GoBS *2 durch das zu prüfende Software-Produkt.
Durch eine ähnliche Ausrichtung revisionsspezifischer DV-Prüfungen und einer Prüfung der Software zur Testaterlangung hat dieses Gütesiegel für die Revision einen besonderen Stellenwert. In der Praxis wird mit Hinweis auf das vorliegende Testat eine Prüfung durch die Revision als überflüssig empfunden, da ja bereits eine umfassende Prüfung eines unabhängigen Dritten vorliegt.
Dieser weit verbreiteten Auffassung muß widersprochen werden.
Grundsätzlich beziehen sich diese Testate nicht auf das Softwareprodukt im Allgemeinen, sondern auf eine bestimmte Software-Versionsnummer mit einem Release-Stand zu einem festgelegten Zeitpunkt. Handelt es sich also bei der zu prüfenden Software um einen anderen Release-Stand oder eine Weiterentwicklung der Software in Form einer neuen Version, ist das Testat zwar ein Hinweis auf eine zu einem früheren Zeitpunkt testierte Software, gibt aber keinerlei Anhaltspunkte auf eine ordnungsmäßige Abwicklung innerhalb des Programmes zum aktuellen Zeitpunkt.
Darüber hinaus läßt sich der Umfang des Testats erst nach Kenntnis des genauen Wortlautes ermessen. Häufig besagt dieser, daß die vorliegende Software nach den Grundsätzen ordnungsmäßiger Buchführung eingesetzt werden kann.
Das bedeutet, daß erst bei einem Vergleich der innerhalb des Customizing festgelegten Softwaresteuerungsparameter der zu prüfenden Software mit den Parametern der mit einem Testat versehenen Softwareversion beurteilt werden kann, ob die getroffene Aussage auch auf das zu prüfende Softwareprodukt zutrifft.
Häufig werden auf Grund spezifischer Kundenwünsche die Parameter geändert, damit die Software sich weitestgehend der Ablauforganisation im zukünftigen Einsatzgebiet anpaßt.
Als letztes Argument, bezogen auf den Stellenwert dieser Testate, sei hier angefügt, daß derartige Prüfungen in Einsatzumgebungen durchgeführt werden, die speziell für diese Prüfung eingerichtet wurden.
In der Praxis wirken störende Einflüsse.
Hierarchisch aufgebaute Softwareebenen wie Betriebssystem, Netzwerkumgebung und die Anwendersoftware beeinflussen sich gegenseitig.
Ein weiteres Beispiel für Beeinflussungsmöglichkeiten besteht durch direkt ineinander greifende Softwaresysteme: Verbindungen sind über Schnittstellen zur Datenübergabe möglich oder allein dadurch, daß gleichzeitig vom Anwender genutzte Software die gleichen Hauptspeicher-Bereiche oder Interrupts belegt.
Hierdurch kann eine Instabilität des Systems hervorgerufen werden, die Datenverluste oder nicht vorhergesehene Verarbeitungen zur Folge hat. Damit wird eine Prüfung unumgänglich.
Bei der Einschätzung der Wertigkeit testierter Software ist zu berücksichtigen, daß es bisher keine Richtlinien und Vorgaben für das Vorgehen und den Umfang der Prüfung gibt, die zur Testatvergabe führen. Die Prüfungen beziehen zwar immer die GoB, beziehungsweise die GoBS mit ein, wie weitreichend und umfassend eine derartige Prüfung jedoch ist, liegt im Ermessen des Prüfers.
Als Grundlage hierfür kann er die oben zitierte DIN ISO/IEC 12119 von 1994 oder die Fachmitteilungen der Schweizerischen Treuhand- und Revisionskammer Nr.9 zur Softwarezertifizierung von 1988 heranziehen. Darüber hinaus steht ihm die Stellungnahme des FAMA 1/1987 i.d.F. von 1993 Grundsätze ordnungsmäßiger Buchführung bei computergestützten Verfahren und Prüfungen zur Verfügung, die sich auf bereits eingesetzte und freigegebene Verfahren bezieht.
Eine Aussage zur Qualität der vorgenommenen Testierung ist damit erst nach genauer Kenntnis des für die Testatvergabe erstellten Berichts mit Bestätigungsvermerk möglich.
Eine Heranziehung für die eigene Prüfung ist grundsätzlich nur unter Berücksichtigung des Fachgutachtens 1/1988 Grundsätze ordnungsmäßiger Durchführung von Abschlußprüfungen zulässig, wonach Ergebnisse von sachverständigen Dritten verwendet werden dürfen, diese aber grundsätzlich einer Nachprüfung, stets aber einer kritischen Würdigung durch den Revisor unterliegen.
Eine Prüfung der genauen Einsatzumgebung des Hard- und Softwareumfeldes sowie des in Verbindung mit der Software errichteten internen Kontrollsystems (IKS) ist in jedem Fall Prüfungsgegenstand der Softwareprüfung und kann durch keine Testierung im Vorfeld gespart werden.
Seit Juni diesen Jahres liegt nun ein Entwurf des Hauptfachausschusses (zukünftig HFA) des IDW *3 zur Erteilung und Verwendung von Software-Bescheinigungen vor. Dieser soll die bisherige Unsicherheit von Prüfern bei der Testat-Vergabe durch eindeutige Festlegung der hierzu notwendigen Verfahrensprüfung und Berichterstattung beseitigen.
Im Verhältnis zu einem bereits früher vorliegenden Entwurf des FAMA aus 1996 steht dieser Entwurf für eine umfassende Prüfung, angelehnt an die gesetzlichen Grundlagen des Handelsgesetzbuches *4 und der Abgabenordnung *5 in Verbindung mit der FAMA-Stellungnahme 1/1987 i.d.F. 1993 Grundsätze ordnungsmäßiger Buchführung bei computergestützten Verfahren und deren Prüfung sowie den GoBS.
Im Gegensatz zu dem ersten weitgefaßten Entwurf, der sich auf rechnungslegungsnahe Software generell bezog, zielt der neue Entwurf auf Softwareprodukte, die für die Ordnungsmäßigkeit der Rechnungslegung von Bedeutung sind, ab.
Er schafft mit seinen ausführlichen und umfassenden Vorgaben erstmals Klarheit, nach welchen Kriterien und Prüfungen Software-Testate vergeben werden dürfen und schlägt die Form eines festgeschriebenen Bestätigungsvermerkes am Ende der Prüfung vor. Dieses kann entweder vom Prüfer aus besonderem Grunde versagt oder gegebenenfalls dann eingeschränkt werden, wenn einzelne abgrenzbare Teilmodule der zu prüfenden Software als fehlerhaft erkannt werden.
Der Entwurf berücksichtigt auch die anschließende Verwendung des Berichts zur Testatvergabe für spätere Prüfungen der Software durch die interne Revision oder beispielsweise den Wirtschaftsprüfer bei der Jahresabschlußprüfung in der Einsatzumgebung.
Voraussetzung ist hierfür die Aushändigung eines aussagefähigen Berichts über die Softwareprüfung und eine kritische Würdigung der Prüfungsergebnisse durch den Prüfer, wie im Fachgutachten 1/1988 Grundsätze ordnungsmäßiger Durchführung von Abschlußprüfungen gefordert wird.
Darüber hinaus ist nach diesem Entwurf die Einbeziehung des zur Testatvergabe erteilten Prüfungsberichtes in Berichte interner und externer Prüfer nur dann zulässig, wenn die Aussagen der Software-Bescheinigung keine wesentlichen Einschränkungen beinhalten, der Versions- und Release-Stand mit dem der eingesetzten Software übereinstimmt und die Systemumgebung der eingesetzten und der bescheinigten Software identisch, zumindest aber kompatibel sind.
Trotz vorliegenden Prüfungsberichtes ist eine Prüfung folgender Bereiche unumgänglich:
- der Systemumgebung einschließlich der entsprechenden internen Kontrollen
- der richtigen Bedienung des Programmes sowie
- der zutreffenden Einstellungen der Softwaresteuerungsparameter (die während des Customizings festgelegt wurden).
Grundsätzlich kann eine Softwareprüfung eine DV-Systemprüfung im Bereich der Ablauforganisation des DV-Bereichs nicht ersetzen. Weiterhin geprüft werden muß insbesondere die Funktionentrennung innerhalb der DV-Abteilung, die Arbeitsabwicklung in der DV korrespondierend mit der in der Fachabteilung sowie die Sicherung der Funktionsfähigkeit der DV.
Zusammenfassend läßt sich feststellen, daß der neue Entwurf des HFA zur Erteilung und Verwendung von Software-Bescheinigungen erstmalig Klarheit über den Umfang von Prüfungen zur Vergabe von Testaten für Software, die für die Ordnungsmäßigkeit der Rechnungslegung von Bedeutung sind, bringt.
Darüber hinaus räumt dieser Entwurf endgültig mit der allgemein verbreiteten Annahme auf, bereits einmal testierte Software bedürfe keiner weiteren Überprüfung. Unabhängig von den im Detail an diesem Entwurf noch vorzunehmenden Änderungen sowie des noch nicht feststehenden Verabschiedungstermins durch den HFA wird hiermit erstmalig durch eine für Revisoren maßgebliche Institution Stellung zu testierter Software genommen.
Eine nach dieser Vorlage testierte Software bietet bei vergleichbarer Installationsweise und gleichem Versions- und Release-Stand einen hohen Aussagewert über die Qualität der Software und Datenhaltung. Vom Aspekt des Prüfungsaufwandes her betrachtet reduziert sich der Prüfungsumfang für testierte Software in der Einsatzumgebung im Vergleich zu nicht testierter Software jedoch nur in geringem Maße.
