≡ Menu

Automatisierte Tests sind wie Checklisten

Seien wir ehrlich: Softwareentwicklung ist harte Arbeit. Es geht nicht nur darum, einer Maschine beizubringen etwas zu tun — das wäre ja einfach! Nein, es geht vor allem darum dafür zu sorgen, dass ich und andere in Zukunft daran weiterarbeiten können. Automatisierte Tests helfen dabei.

Wie muss man sich solche Tests vorstellen? Automatisierte Tests sind wie Checklisten, die ich schreibe und der Computer überprüft.

Eine solche Liste formuliert Anforderungen an die Software. Spezielle Programme arbeiten diese Listen Punkt für Punkt ab und zeigen, wo die Software sich anders verhält als gewollt.

Jeder, der sich einmal bei einer E-Mail-Adresse vertippt hat, weiß, wie pingelig Computer sein können, wenn etwas nicht genau ihren Erwartungen entspricht. Die Dinger sind ganz schön stur, gell?

Genau das macht man sich in Tests zunutze.

Dokumentation und Sicherheitsnetz in einem

Was bringen automatisierte Tests? Zunächst einmal eine rudimentäre Dokumentation, was die Software alles kann (vorausgesetzt, alle Tests laufen ohne Fehler durch und sind selbst nicht fehlerhaft programmiert).

Außerdem wird die Wartbarkeit der Software mit Tests erhöht. Jede noch so kleine Änderung kann Auswirkungen auf das Verhalten des gesamten Systems haben, wie auch XING weiß:

Jede neue Codezeile in einem Programm kann die exisitierenden Funktionalitäten beeinträchtigen.

Irgendwie beängstigend, oder? Ohne Tests ist man da als Entwickler weniger motiviert, Änderungen vorzunehmen. Mit Tests sieht die Sache anders aus.

Brillante Idee für ein neues Feature? Schreibe einen Test und entwickle dann die Funktion.

Unleserlicher Programmcode, der zwar tut was er soll, aber trotzdem verbessert werden muss? Kein Problem: Tests geben einem das gute Gewissen, dass sich am Verhalten der Software nichts geändert hat.

Bug gefunden? Der lässt sich mit einem Test nachstellen und dann beheben. So ist man davor geschützt, denselben Fehler nochmal zu machen.

Think big

Für große Projekte ist ein Argument für Tests unschlagbar: Wirtschaftlichkeit. Tests machen Änderungen an großen Systemen überhaupt erst möglich. Software zu warten, die über Jahrzehnte gewachsen ist und deren erste Autoren die Firma längst verlassen haben, ist ohne Tests ein Albtraum. Häufig ist eine Neuentwicklung unumgänglich — und das kostet!

Für Kunden heißt das übersetzt: Tests sichern die Weiterentwicklung. Und das kann nur gut sein.

Die Kehrseite der Medaille

Natürlich können Tests genauso fehlerhaft sein wie andere Programme auch. Dagegen hilft meist nur Erfahrung, um Probleme zu erkennen und zu vermeiden.

Auch die Investition, die für die Entwicklung von Tests notwendig ist, ist nicht zu vernachlässigen: Nicht selten sind Tests länger als die eigentlichen Programme — sogar in einem Mini-Projekt wie Headhunter ist der Test mehr als doppelt so lang wie das Programm selbst.

Ausblick

Dieser Aufwand ist es scheinbar auch, was manchen Manager davon abhält, in Tests zu investieren. Schade. Solche Firmen werden es in Zukunft schwer haben, Nachwuchs-Entwickler zu finden.

Man kann nur hoffen, dass sich Tests auch bei Kleinst-Projekten durchsetzen. Gerade für Hobbyprojekte kann es durchaus hilfreich sein, das vollständig getestete Programm an jemanden abzugeben, wenn man selbst keine Zeit mehr hat.

[Foto von Jen Rabulan-Bertram, CC-Lizenz]

Comments on this entry are closed.

  • Banana 27. April 2010, 08:50

    Wenn ich das gerade so lese überlege ich mir, ob man für die Tests nicht auch gleich noch einen Test entwickeln sollt, ob dieser überhaupt so läuft wie er soll ;-) Ich gehe einfach mal davon aus, dass diese Tests ja selbst auch schon ein Programm darstellen und ich mir, um diese zu Entwickeln, erst mal im klaren darüber sein muss, was das Programm am Ende alles genau machen soll und wie, oder habe ich das jetzt falsch verstanden? Wären dann nicht eigentlich zwei Entwickler vom Vorteil? Einer der den Test entwickelt und einer, der das eigentliche Programm entwickelt?

  • André 27. April 2010, 21:46

    Danke für die zahlreichen Fragen.

    Zur Frage, ob Tests selbst nicht auch getestet werden sollten: Software und die zugehörigen Tests sind völlig anders aufgebaut. Um neue Funktionalität zu integrieren, wird Software nicht nur ergänzt, sondern vor allem auch umgeschrieben. Tests werden meist nur ergänzt, weil sie nicht so komplex sind (oder sein sollten). Durch diese Einfachheit erübrigt sich ein Test des Tests. Natürlich kann es immer noch vorkommen, dass Tests fehlerhaft sind, aber das fällt meist zeitnah auf.

    Hinzu kommt, dass man bei test-getriebener Entwicklung erst einen einfachen Test schreibt, der fehlschlägt. Dann kommt ein kleines Stück Programmcode, um den Test zu erfüllen. Dann wieder ein Test für den nächsten Schritt usw. Das erschwert das Schreiben eines falschen Tests.

    Zum Thema Entwickler und Tester: Das funktioniert selten, weil sich Tests und Programmcode nicht so strikt trennen lassen — ständige Absprachen würden den Arbeitsfluss stören. Außerdem schafft man mit diesen sehr speziellen Rollen nur Probleme, wenn eine der beiden ausfällt. Dann macht es mehr Sinn, in Zweiergruppen zu entwickeln (“Pair Programming”) oder eine andere Art von Peer Review zur Qualitätssicherung zu etablieren.

    Ich hoffe, damit noch etwas Licht ins Dunkel gebracht zu haben.

  • Sebastian 1. Juni 2010, 15:19

    Wie wärs mit einem kleinen HOWTO wie man so ein Test anlegt :) Also ich hätte Interesse dran.
    Gruß