Testing-Empfehlungen für Entscheider Software mit automatisierten Tests absichern

Anbieter zum Thema

OutSystems

Automatisierte Tests sind die Voraussetzung dafür, geschäftskritische Software langfristig und erfolgreich zu betreiben. Um Softwaretests effektiv und zugleich kostensparend einzusetzen, sollten einige wichtige Grundprinzipien beachtet werden.

Viele Unternehmen scheuen den vermeintlichen Aufwand und die Kosten, die mit der Implementierung automatisierter Software-Tests verbunden sein können. Dabei wird oft ausgeblendet, dass gerade nicht getestete Software immense Kosten verursachen kann.

Bei automatisierten Testverfahren geht es darum, mit selbst entwickelter Testsoftware ein Softwareprodukt ohne manuelle Eingriffe zu überprüfen. Das Ziel ist dabei, die korrekte Ausführung möglichst aller Funktionen der Software zu gewährleisten. Die Automatisierung ermöglicht, diese Überprüfung sehr schnell und damit häufig vorzunehmen.

Wurde Software umfassend mit automatisierten Tests entwickelt, resultieren daraus wesentliche Vorteile. Programmierfehler werden frühzeitig erkannt, da Entwickler durch die Tests eine sofortige Rückmeldung über unerwünschte Nebenwirkungen ihrer Code-Änderungen erhalten. Damit lassen sich Folgekosten vermeiden.

Die Auswirkungen von Fehlern werden umso teurer, je später sie entdeckt werden. Während der Entwicklung identifizierte Bugs lassen sich leicht und mit verhältnismäßig geringem Aufwand beheben. Ist fehlerhafte Software aber erst einmal bei den Anwendern im Einsatz, sind Auswirkungen und Kosten unvorhersehbar und führen oft zu großem Unmut und einer hastigen Rückruf- oder Nachbesserungsaktion.

Automatisierte Tests ermöglichen nicht nur eine kosteneffiziente und qualitätsgesicherte Entwicklung von Software, sondern auch ihre Anpassung. Somit bleibt man in dynamischen Märkten handlungsfähig, weil Anpassungen schnell und risikolos produktiv eingesetzt werden können. Unternehmen können schneller auf den Wettbewerb reagieren, da die getestete Software flexibel genug ist, die wechselnden Anforderungen des Marktes auch abbilden zu können

Gerade für eine agile, iterative Entwicklung (Stichwort: Continuous Integration/Deployment), garantieren die Tests, dass neue Features funktionieren und bestehende Funktionen nicht beeinträchtigen. Auch ein gefahrloses Umstrukturieren des Codes (Refactoring) wird möglich. Dies ist erforderlich, damit die Software zeitgemäß bleibt. Automatisierte Tests stellen sicher, dass durch Refactoring keine Fehler entstehen. Sie sorgen also dafür, dass die Software veränderbar und flexibel bleibt und zugleich fehlerfrei und stabil läuft.

Die wichtigsten Grundprinzipien des Testens

Um allgemein von Software-Testing zu profitieren, sollten folgende Punkte beachtet werden:

• Ins Blaue hinein zu programmieren ist nicht hilfreich. Bei der Strukturierung der Software müssen Regeln eingehalten werden, so dass sie gut testbar ist.

• Die Tests sollten wenn möglich automatisiert stattfinden, da manuelles Testen mit einem hohen Zeitaufwand verbunden ist. Lassen sich manuelle Tests nicht vermeiden, sollten sie systematisch erfolgen. In Testkatalogen muss dann erfasst werden, wann wie getestet wird. Auch Sonderfälle sollten abgebildet werden.

• Es muss auf den drei Ebenen Unit, Integration und System getestet werden. Sie unterscheiden sich in Art und Umfang, und auch der Verantwortungsbereich variiert:

Unittests werden von Entwicklern programmiert: Kleine Code-Einheiten werden separat getestet. Im Falle einer Login-Seite wird zum Beispiel ein Passwort abgefragt, für das gewisse Regeln eingehalten werden sollen. Über Unittests wird geprüft, dass der Code so implementiert wurde, dass die Vorgaben von der Software tatsächlich berücksichtigt werden.

Auf der zweiten Ebene der Integrationstests zeichnen die Entwickler verantwortlich. Über Integrationstests werden mehrere Bausteine und Komponenten auf einmal getestet – Systeme im Verbund. Integrationstests sind wichtig, aber auch aufwändiger und komplexer im Aufbau und der Durchführung.

Die dritte Ebene der Systemtests ist am aufwändigsten, denn sie wird üblicherweise auf dem Gesamtsystem ausgeführt und simuliert die Bedienung des Systems durch den Anwender. Deshalb bezeichnet man sie auch als Akzeptanztests: Sie werden in natürlicher Sprache formuliert und können daher gemeinsam mit dem Kunden oder vom Kunden selbst aufgesetzt werden. Die Überprüfung einer Passwortregel als Akzeptanztest würde zum Beispiel wie folgt lauten: „Wenn ich als Anwender im Registrierungs-Dialog als Passwort eine Zeichenkette ohne Großbuchstaben eingebe, dann wird die Registrierung abgelehnt und es erscheint ein Hinweis zu den Passwortregeln.“ Es ist sinnvoll, den Auftraggeber hier einzubeziehen und mit ihm ein Anforderungsmanagement zu betreiben. Formuliert der Kunde seine Wünsche direkt in Form von Tests, wird sichergestellt, dass seine Anforderungen erfüllt sind. Damit können die Akzeptanztests als Kriterium für die Abnahme der Software durch den Kunden herangezogen werden.

• Alle geschäftskritischen Funktionen der Software sollten getestet werden. Um die perfekte Abdeckung zu finden, muss eine geschickte Kombination aller drei Ebenen gewählt werden – das erfordert immer ein Abwägen von Zeit, Geld und Qualität. Die drei Kategorien benötigen unterschiedliche Ressourcen, sind unterschiedlich komplex und unterschiedlich aufwändig zu pflegen und durchzuführen.

Die Empfehlung für die Kombination der Tests ist, so umfangreich wie möglich auf den unteren Ebenen zu testen. Damit verringert sich die Laufzeit der Tests und sie können problemlos häufig ausgeführt werden. Um Tests nicht nur aus Entwicklersicht, sondern aus unterschiedlichen Blickwinkeln durchzuführen, sollte es aber in jedem Fall auch Akzeptanztests geben.

• Bezüglich ihrer Laufzeit optimierte Tests können von Anfang an in die Entwicklung eingebunden werden und finden ständig und nach jeder Änderung automatisiert statt. Sie werden damit immer auf dem aktuellen Stand der Software durchgeführt.

Die Anzahl der Tests hängt vom Umfang des Projekts ab – cronn integrierte zum Beispiel für eine Software mit 250 000 Zeilen Code mehr als 25 000 Tests. Hier wird deutlich, dass dieser Umfang manuell nicht leistbar ist. Während diese Tests in etwa einer Stunde automatisiert durchgeführt werden können, wären bei manueller Abdeckung der Testfälle vermutlich mehrere Angestellte mehrere Wochen lang im Einsatz.

Die fünf häufigsten Ausreden, wieso auf Tests verzichtet wird

Automatisierte Tests sind nicht gang und gäbe und werden gern als zusätzlicher Kostenfaktor wahrgenommen. Häufig genannte Argumente gegen automatisierte Tests sind allerdings leicht zu entkräften.

1) Die Software wurde ohne Tests entwickelt und es ist nachträglich nicht möglich, Tests zu implementieren.

Das ist so nicht richtig: Die nachträgliche Implementierung ist zwar in der Tat mit Aufwand verbunden, aber nicht unmöglich. Zumindest Akzeptanztests auf dem Gesamtsystem sind fast immer auch nachträglich umsetzbar und sollten für die kritischsten oder am häufigsten benötigten Funktionen umgesetzt werden. Auf der Unit- und Integrationstestebene ist der Aufwand einer ggf. erforderlichen Codeumstrukturierung gegen den Nutzen abzuwägen.

2) Bei der Neuentwicklung wären Tests zu aufwändig und zu teuer.

Zwar ist es korrekt, dass die Entwicklung mit Tests zunächst mit Mehrkosten verbunden ist. Doch unterm Strich steht ein vielfacher ROI: Die Software kann erstens langfristiger betrieben werden und zweitens können jene Kosten gespart werden, die überhaupt erst wegen fehlender Tests entstehen.

3) Testszenarien sind nur schwer zu entwickeln.

Manch eine Software besitzt zahlreiche Schnittstellen zu anderen Applikationen (z.B. CRM, Billing, o.ä.), in anderen Fällen ist das Gesamtsystem sehr komplex. Doch auch hierfür gibt es Methoden und Ansätze, Tests für entsprechende Konstellationen aufzusetzen. Für externe Applikationen kann zum Beispiel mit Mocks oder Dummys gearbeitet werden, die bei der Ausführung von Tests das Verhalten dieser Komponenten simulieren. Dieser Aufwand sollte nicht gescheut werden.

4) In der IT fehlt die Expertise.

Natürlich brauchen Entwickler und Tester das nötige Knowhow, denn das Programmieren von Software mit automatisierten Tests ist leichter gesagt, als getan. Man muss wissen auf welchen Ebenen welcher Test laufen soll und braucht außerdem kreative Ideen. Doch wenn das Knowhow intern nicht vorhanden ist, kann ein externer Dienstleister Unterstützung anbieten – es muss auch nicht zwangsläufig das Unternehmen sein, das die Software geschrieben hat.

5) Es gibt keine geeigneten oder nicht ausreichend viele Testdaten.

Das muss kein Hindernis bleiben – man kann Testdaten mit Hilfe von Skripten oder Softwaretools selbst generieren. Gerade bei Massentests ist dies eine übliche Vorgehensweise.

Die wichtigsten Handlungsempfehlungen für Entscheider

Der erste Schritt muss darin bestehen, den Status Quo herauszufinden: wird die Software bereits getestet und wenn ja, wie geschieht dies genau? Je nach Konstellation ist der Ansprechpartner dabei entweder die hauseigene IT oder der IT-Dienstleister.

IT und Dienstleister müssen dann befragt werden, welche Applikation mit Tests für welche Fälle und in welchem Umfang abgesichert sind. Hier bietet es sich an, sich Testfallkataloge zeigen lassen, um die Testabdeckung und den Automatisierungsgrad zu erkennen: Gibt es Tests auf verschiedenen Ebenen oder nur auf einer?

Wichtig ist außerdem, keine Ausreden für einen Verzicht zu akzeptieren. Keine Frage, die nachträgliche Implementierung oder die Neuprogrammierung mit Tests ist mit Aufwand verbunden. Langfristig zahlt sie sich aber mehr als aus. Fehlt die Expertise im Haus, kann diese extern zugekauft werden. Ist die nachträgliche Implementierung von Tests in bestehende Software nicht möglich, müssen Neuentwicklungen und Erweiterungen an der Software zumindest in der Zukunft mit Tests abgesichert werden. So kann man schrittweise den Weg in Richtung getesteter Software beschreiten.

Fazit

Wer geschäftskritische Software langfristig erfolgreich betreiben will, muss sie mit Tests absichern. Nur sie gewährleisten die Veränderbarkeit der Software und damit ihre Langlebigkeit. Veränderungen können dabei ständig, kurzfristig und risikominimiert vorgenommen werden.

Hemmnisse wie zum Beispiel hohe Kosten müssen in Relation gesetzt werden. Denn schließlich werden jene Kosten eingespart, die überhaupt erst wegen fehlender Tests entstehen können. Klar ist: automatisierte Tests sind kein Selbstläufer – sie wollen konsequent vorbereitet und sinnvoll eingeführt sein. Eine fehlende Inhouse-Expertise können externe Partner kompensieren.

* Jobst Eßmeyer ist Gründer und Geschäftsführer der cronn GmbH. Seit seiner Jugend entwickelte er Software für Kunden mit individuellen Fragestellungen. Nach dem Abschluss als Diplominformatiker an der RWTH Aachen arbeitete er bis zur Gründung von cronn als selbständiger Berater für moderne Softwareentwicklung in unterschiedlichen mittelständischen Unternehmen und Konzernen. Zahlreiche Projekte schärften seinen Blick auf die Vorzüge und Nachteile von Standardsoftwareprodukten und auf die Entwicklung individueller Lösungen. Bereits vor 15 Jahren setzte Eßmeyer aus Überzeugung auf agile, testgetriebene Entwicklung. Diese DNA ist fester Bestandteil der Unternehmenskultur von cronn.

(ID:46403988)