Anzeigen

Anbieter von Lösungen zur elektronischen Steuerprüfung
hmd Solftware
Verfahrensdoku
DATEV eG
GISA
Caseware
Home

Testen und Testieren

Editorial des Email-Newsletters 12-2008 vom 11.12.2008


Gerhard Schmidt

Wer Software verkaufen will, will in aller Regel ein ordentliches Produkt auf den Markt bringen. Eine der wichtigsten Maßnahmen der Qualitätssicherung bei der Softwareentwicklung ist das Testen. Testen ist aufwändig. Rund 40 Prozent der Gesamtkosten, die bis zum ersten Einsatz einer Software entstehen, werden für Softwaretests ausgegeben. Wenn ein Softwarehaus sich beim Testen schon so viel Mühe gegeben hat, dann will es das seinen Kunden gegenüber auch dokumentieren. Am besten durch ein Qualitätssiegel. Das kann sich das Softwarehaus schlecht selbst verleihen. Also beauftragt es damit einen externen Zertifizierer. Einen (auf IT spezialisierten) Wirtschaftsprüfer beispielsweise. Ein Zertifizierer muss zweierlei prüfen. 1. Ob die an ein Produkt dieser Art zu stellenden Anforderungen Teil des Pflichtenheftes für die Softwareentwicklung waren und 2. Ob die Software diese Anforderungen auch tatsächlich erfüllt. Nehmen wir einmal an, es geht um eine Software, die GoBS-konform sein muss. Ob die Anforderungen an GoBS-Konformität der Programmierung zugrunde gelegt wurden, lässt sich leicht feststellen. Doch ob die Anforderungen auch erfüllt werden? Wenn auf einer Taste (oder Schaltfläche) steht: „GoBS-konform verbuchen“, kann dies plausibilisiert werden. Ein paar Buchungen (zulässige und unzulässige) eingeben und schauen, was dabei passiert. Macht man dies umfangreich und systematisch, nennt man es Black-Box-Test. Kann aber auch ausgeschlossen werden, dass es keine versteckte und nirgendwo dokumentierte Taste (oder wilde Tastenkombination) gibt mit der Bedeutung „GoBS-widrig verbuchen“? Im Prinzip schon. Dann müsste man sich aber in einem White-Box-Test mit der inneren Programmstruktur auseinandersetzten. Doch welcher Wirtschaftsprüfer kann schon programmiersprachlichen Quell-Code lesen? Und wenn er es kann, welcher Auftraggeber würde ihm die viele Zeit bezahlen, die es braucht, sich durch so ein Programm zu wühlen? Nur um nachweisen zu können, dass es im Programm kein verstecktes Hintertürchen gibt? Softwaretestate basieren also wesentlich auf einer Prüfung des Pflichtenheftes der Software und darauf basierender Plausibilitätsbetrachtungen am fertigen Produkt. Die Qualitätskontrolle beim Testieren ist damit viel oberflächlicher als die Qualitätskontrolle durch Testen. Welchen Wert hat dann ein Softwaretestat? Es ist erst einmal hilfreich im Marketing, denn testierte Software lässt sich besser verkaufen. Kaum ein Kunde wird sich das Kleingedruckte im Testat durchlesen, in dem oft – aus gutem Grund – die Aussagekraft des Testats eingeschränkt wird. Hilfreicher ist ein Softwaretestat allerdings im Konfliktfall. Wer vor einem Betriebsprüfer oder einem Finanzrichter mit einem Softwaretestat (etwa zur GoBS-Konformität) wedelt, ist erst einmal fein heraus. Gibt es für den Konfliktgegner hinreichende Gründe, das Testat anzuzweifeln? Lohnt es sich gegebenenfalls für viel Geld ein Gegengutachten einzuholen? Das ist doch eher unwahrscheinlich. Wir sehen: Testieren dient vor allem der psychologischen Qualität einer Software. Die technische Qualität der Software sichert das Testen.

Ihr Gerhard Schmidt

Newsletter
 hier abonnieren
Editorial 2008-12: Testen und Testieren

02.10.2024

powered by webEdition CMS
powered by webEdition CMS