Der Kunde fordert es, der Sales verspricht es und die Projektleiterin und ihr Team müssen es möglich machen: qualitativ hochwertige Systemlösungen in kurzer Zeit implementieren. Aber, wie soll das funktionieren?
Es ist nichts Neues. Zeit und Qualität hängen stark miteinander zusammen. Je mehr Zeit man für ein Projekt zur Verfügung hat, desto höher kann der Qualitätsstandard sein. Nur ist die Zeit meistens aus Kostengründen knapp bemessen. Wie soll man es also trotzdem schaffen, in kurzer Zeit eine hochwertige Softwarelösung zu implementieren? Eine Möglichkeit ist die testgeleitete Softwareentwicklung oder „Test Driven Development“ (TDD). Dabei handelt es sich um eine Designstrategie für Softwareentwicklung, bei der sogenannte Unit-Tests zeitgleich mit dem Produktionscode geschrieben werden.
Viele haben davon gehört, wenige setzen es um. „Es ist teuer!“, „Das lohnt sich nicht für so ein kleines Projekt!“, „Wir haben doch keine Zeit!“, „Hier muss alles schnell gehen“. Man könnte hier noch viele weitere Ausreden aufzählen, aber es würde nichts daran ändern, dass es eben nur Ausreden sind.
Unsere Erfahrung zeigt, dass man mit TDD in kurzer Zeit und mit einem hohen Standard Softwarelösungen oder einzelne Funktionalitäten implementieren kann.
Na dann lassen sie sich mal überraschen. Man muss es einfach nur richtig machen. Dafür benötigt man aber ein bisschen Erfahrung. Darum lassen wir Sie an unserer teilhaben. Hier haben wir für Sie die wichtigsten Faktoren für erfolgreiche TDD zusammengestellt.
Als erstes muss man sich von der Erwartung verabschieden, dass man einfach eine Testabdeckung von 100 Prozent vorschreiben kann. Auch wenn es vielleicht wünschenswert ist, erreicht man auch mit dem konsequentesten Einsatz von TDD wohl eher nur die 80 Prozentmarke. Natürlich variiert dies stark mit den einzelnen Aufgaben. Seien Sie aber nicht traurig darüber, sondern freuen sich des Lebens. Denn die Erfahrung zeigt, dass bei einer vorgegeben hohen Abdeckungsrate, viele Tests sowieso nur für die Erreichung dieser geschrieben werden. So verlieren die Tests und schlussendlich das Gesamtsystem an Qualität und werden zum Wartungsproblem.
Befolgen sie diese drei simplen Regeln von R.C. Martin (Clean Code):
Sind wir mal ehrlich, eigentlich gibt es keinen Fall, wo ein schlampiges Ticketing erlaubt ist. Für den Erfolg von TDD muss dieses wirklich gewissenhaft geführt werden. Das heisst, der Ticketinhalt muss genau spezifiziert und der Arbeitsaufwand vernünftig eingeschätzt werden. Damit man auch so richtig TDD praktizieren kann, muss es sich beim umzusetzenden Task um eine „Business Logik“-Aufgabe handeln und z.B. nicht nur eine Frontend-Anpassung oder Systemkonfiguration. Zu Beginn werden die Teammitglieder sicher etwas über die neuen Ticketing-Richtlinien stöhnen, sobald sich aber die Regeln in den Köpfen der Leute festgesetzt haben, wird es wieder ruhiger im Büro.
Selbstverständlich sollte jeder Code, der geschrieben wird, ob mit oder ohne TDD den Clean-Code-Prinzipien entsprechen. Also halten Sie sich auch bei TDD dran.
Das altbekannte „Aber das treibt doch die Projektkosten in die Höhe!“ kommt bei TDD so sicher, wie das Amen in der Kirche. Wenn der Kunde ein Projekt in Auftrag gibt, geht er davon aus, dass die Softwarelösung qualitativ hochwertig und einfach zu warten sein wird. Und da hat er ja auch recht damit. Die Kunden profitieren zwar von TDD aber die wahren Gewinner sind die IT-Dienstleister, die es in den Organisationen integrieren. Der Aufwand für die Ausbildung der Entwickler zahlt ich schnell durch weniger Wartung, zufriedenere Kunden und produktivere Mitarbeiter aus. Denn bei TDD geht es nicht nur darum eine Programmiertechnik einzuführen. Es geht darum eine gesamtheitliche Unternehmensstrategie zu unterstützen, die darauf abzielt, dem Kunden kontinuierlich höchste Software-Qualität zu liefern. Darum ist es eine Investition des IT-Dienstleisters in die Qualität seines eigenen Produktes.