Softwaretestat nach IDW PS 880: Ablauf und Kriterien

Was ein Softwaretestat aussagt

Der IDW Prüfungsstandard 880 regelt die Prüfung von Softwareprodukten durch Wirtschaftsprüfer. Gegenstand ist nie die gesamte Organisation eines Herstellers, sondern ein klar abgegrenztes Produkt in einem bestimmten Versionsstand. Das Ergebnis ist ein Prüfungsbericht mit Prüfungsurteil. Auf dieser Grundlage kann eine Softwarebescheinigung erteilt werden, die Hersteller ihren Kunden und deren Abschlussprüfern vorlegen.

Die Bescheinigung ersetzt nicht die Verantwortung der Anwender für ihre eigenen Prozesse. Sie schafft aber eine unabhängige Grundlage, auf die sich Anwender und deren Prüfer stützen können, statt jedes Produkt selbst einzeln zu untersuchen.

Wann Kunden ein Testat verlangen

• Die Software wird in rechnungslegungsrelevanten Prozessen eingesetzt, etwa in Buchhaltung, Abrechnung, Zahlungsverkehr bzw. Lohn.
• Der Abschlussprüfer eines Anwenders benötigt Nachweise, dass die Software ordnungsgemäß arbeitet.
• Ausschreibungen bzw. Aufsichtsanforderungen setzen einen unabhängigen Nachweis voraus.
• Der Hersteller möchte wiederkehrende Kundenanfragen und Einzelprüfungen durch einen Nachweis ersetzen.

Welche Kriterien Prüfer anlegen

Die Prüfung ist risikoorientiert. Der Prüfer verschafft sich zunächst ein Verständnis des Produkts und bewertet dann, wo die wesentlichen Risiken liegen. In der Praxis stehen fünf Fragen im Mittelpunkt:

• Ist der Prüfungsgegenstand eindeutig abgegrenzt, einschließlich Versionsstand und Komponenten Dritter?
• Sind Anforderungen, Verfahrens- und Anwenderdokumentation vollständig, aktuell und nachvollziehbar?
• Sind Entwicklungs-, Test- und Freigabeprozess geeignet, Risiken zu beherrschen, und durch Nachweise belegt?
• Setzt das Produkt die festgelegten Kriterien in den relevanten Funktionen um, etwa zu Ordnungsmäßigkeit und Sicherheit?
• Sind Berechtigungen, Änderungs- und Release-Management so geregelt, dass der geprüfte Stand nachvollziehbar bleibt?

Ablauf der Prüfung in fünf Schritten

• Auftragsdefinition: Prüfungsgegenstand, Versionsstand, Kriterien, Umfang und Ansprechpartner werden festgelegt.
• Systemverständnis: Der Prüfer sichtet Verfahrens- und Anwenderdokumentation und identifiziert risikobehaftete Funktionsbereiche.
• Prüfung von Design, Implementierung und Tests: Beurteilt wird, ob der Entwicklungsprozess Risiken beherrscht, stichprobenweise und risikoorientiert.
• Eigene Funktionstests: Der Prüfer verifiziert bzw. ergänzt die Herstellernachweise im Umfang der Risikoeinschätzung.
• Bericht: Nach fachlicher Abstimmung des Entwurfs entsteht der Prüfungsbericht, auf dem die Softwarebescheinigung beruht.

Typische Feststellungen und wie sie vermeidbar sind

• Nicht dokumentierte Tests: Was nicht belegt ist, gilt aus Prüfersicht als nicht durchgeführt. Testfälle, Ergebnisse und Freigaben gehören ins Archiv.
• Unklare Versionsabgrenzung: Wechselt der Prüfungsgegenstand während der Prüfung, drohen Hemmnisse. Ein Einfrieren des Prüfungsstands schafft Klarheit.
• Lücken bei Komponenten Dritter: Externe Bibliotheken, Subdienstleister und Schnittstellen müssen transparent dargestellt sein.
• Fehlende Nachvollziehbarkeit von Änderungen: Release-Management und Berechtigungen sollten den Weg jeder Änderung belegen.

So bereiten Sie sich vor

Ein vorgeschaltetes Readiness-Review zeigt, wo Ihr Produkt und Ihre Prozesse stehen. Im Kern geht es um vier Punkte: Prüfungsgegenstand abgrenzen, Anforderungen und Prozesse dokumentieren, Nachweise zu Tests und Freigaben bereitstellen und den Prüfer früh einbinden. Wer diese Punkte vor Prüfungsbeginn erledigt, verkürzt die Prüfung und vermeidet Überraschungen im Bericht.

Soll das Produkt zusätzlich als Dienstleistung betrieben werden, kommt häufig eine IKS-Prüfung nach IDW PS 951 n.F. bzw. ISAE 3402 hinzu. Beide Nachweise lassen sich abgestimmt planen.