Kolumne: Olis bunte Welt der IT

Alle Fehler getestet?
Kommentare

Getestet wird ungern, dabei bleibt es auch in Zeiten der agilen Entwicklung. Das sollte nicht so sein, denn eigentlich bieten ausführliche automatisierte Tests so viele offensichtliche Vorteile, dass niemand leicht dagegen argumentieren kann.

„Wir haben einen neuen Fehler gemeldet bekommen“, sagt mein Chef, „heute Morgen haben die angerufen. Ich musste eine Stunde am Telefon verbringen, um die zu beruhigen. Ich habe versprochen, dass wir uns heute sofort darum kümmern!“ Das ist Originalton von 1999 – wann immer die Software, die wir mühsam kundenspezifisch gebaut und angepasst hatten, nicht richtig funktionierte, wurde das Telefon in die Hand genommen und angerufen. Dann mussten wir zuhören und nachfragen und diskutieren und beruhigen, und aufschreiben und dokumentieren und begründen und nachweisen. In E-Mails, immerhin, aber auch gern mal in Word oder gar per Briefpost.

„Haben wir das denn noch nie ausprobiert?“, fragt der Chef weiter. Das ist natürlich immer das Problem: Die Benutzer arbeiten tatsächlich mit der Software, und damals hatten wir oft den Eindruck, dass sie regelmäßig Funktionen und Zusammenhänge in unserem Programm fanden, die wir gar nicht kannten oder zumindest nie in der angefragten Weise geplant oder gar getestet hatten.

Natürlich gab es ein Pflichtenheft, das in großem Detail und mit viel Mühe erarbeitet worden war. Wie kann denn da was schiefgehen? Eigentlich ist der Grund dafür ganz einfach, sodass es erstaunlich scheint, dass noch immer in so vielen Betrieben mit Pflichtenheften gearbeitet wird. Eventuell gibt es an manchen Orten andere Betrachtungen, wenn solche Spezifikationen intern erarbeitet werden, unter Mithilfe von Softwareplanern und -entwicklern womöglich, oder sogar die Möglichkeit zur dynamischen Änderung zu späteren Zeitpunkten. Für die Firma, in der ich seinerzeit tätig war, stellte sich die Sache allerdings oft anders dar. Pflichtenhefte waren im Wesentlichen der Versuch von Menschen, die von der Softwareentwicklung keine Ahnung haben, Software zu entwickeln.

Wissen, was der Kunde braucht

Die wichtigste Fähigkeit eines Entwicklers besteht in der Abstraktion. Ein Computer arbeitet entlang bestimmter Linien, die von vielen Faktoren beeinflusst werden: Programmiersprachen und entsprechende Entwicklungsmethoden, Wahl des Betriebssystems oder, etwas allgemeiner, der Ausführungsplattform, bevorzugte UI-Metaphern. Ein Programmierer, oder natürlich ein Team von Programmierern, hat die schwierige Aufgabe, Anforderungen aus der reellen tägliche Arbeit seiner Kunden in diese Schemata zu zwingen. Abläufe müssen analysiert, Zusammenhänge verstanden werden, um die richtigen Algorithmen, die beste UI-Struktur, passende Persistenzmechanismen und ganz allgemein die Prioritäten für die Anwendungsarchitektur korrekt zu definieren.

„Was machen Sie denn den ganzen Tag?“, habe ich dazu schon mal einen (werdenden) Anwender gefragt, nicht genau in diesen Worten, aber sinngemäß. Das Ergebnis dieser einfachen Frage war eine lange Diskussion, denn es war für den Anwender offenbar unvorstellbar, die Tätigkeiten eines typischen Arbeitstags zusammenfassend zu beschreiben. Natürlich wurde erklärt, dass die Frage nicht im Sinn einer Anschuldigung (Sie arbeiten nicht genug!) zu verstehen sei – der Sachbearbeiter bearbeitet Sachen, vermutlich, aber wie bearbeitet er sie denn? Womit fängt ein Vorgang an? Wie sieht der Prozess der Entscheidungsfindung aus? Welche möglichen Wege gibt es in dem Vorgang, und wovon hängt es ab, ob sie beschritten werden? Allein diese Fragen entstehen bereits wieder aus einem Vorgang der Abstraktion: systematisch vorgehen, ein Ziel schrittweise anstreben, darin besteht die Aufgabe. Anwender können das im Allgemeinen nicht.

Zurück zum Pflichtenheft: Es entsteht oft, indem besagte Anwender versuchen, dem Softwareentwickler seine Kernkompetenz streitig zu machen, und in Abwesenheit jeglicher entsprechenden Qualifikationen und Fähigkeiten Software zu „bauen“. Da werden Masken erzeugt und Abläufe in der Software definiert, und der Chef besteht schließlich auf der Umsetzung seiner Lieblingsakronyme WSDL und SOA, weil „das ja jetzt alle machen“. Schlimm ist, dass Aufträge auf solcher Basis irgendwann tatsächlich von der Softwarefirma akzeptiert werden, obwohl man solche Kunden eigentlich lieber nach Hause schicken sollte. Aber auch da gibts einen Chef, der nach all der Investition in Erstberatung und Hilfe bei der Erstellung des Meisterwerks Pflichtenheft natürlich auch den Auftrag haben will.

Wie geht es besser?

Ob mit oder ohne Pflichtenheft, im letzten Millennium entstand viel Software, die nach modernen Gesichtspunkten nicht besonders gut geplant war. Interessanterweise entstanden daraus auch die anfangs beschriebenen Probleme mit der Stabilität. Zusammenhänge in der Software zwischen verschiedenen Teilen der Funktionalität (von außen betrachtet) oder verschiedenen Modulen der Implementation (von „innen“ gesehen, sofern überhaupt Modularisierung betrieben wurde) waren oft unklar. Getestet wurde natürlich. Jedes Mal, wenn ein Programmierer einen größeren Teil neuen Codes geschrieben hatte, startete er natürlich das Programm, um zu sehen, was passierte. Bevor die Software veröffentlicht oder an den Kunden abgegeben wurde, gab es auch eine Testphase, in der Sekretärinnen, Studenten und andere taugliche Kandidaten damit betraut wurden, gewisse Aspekte der Software auszuprobieren. Dafür gab es eventuell sogar Checklisten: „Rechnungswesen – geht da alles?“, „Summe im Lagerbericht nachrechnen!“ und „Neuen Kunden anlegen“ waren typische Einträge.

Nun habe ich im letzten Absatz die beschriebenen Zustände unserer gemeinschaftlichen Unerfahrenheit vor vielen Jahren zugeordnet. Leider ist es aber so, dass viele Projekte auch heute noch unter ähnlichen Umständen durchgeführt werden. Das sollte nicht so sein, und es gibt viele anerkannte Praktiken, mit deren Hilfe bessere Wege beschritten werden können. Agile Entwicklungs- und Planungstechniken stehen meist im Vordergrund, die zu einer stark verbesserten Zusammenarbeit zwischen Kunden, Anwendern und Softwareentwicklern führen können. Allerdings scheint mir, aus meinen Erfahrungen mit Training, Beratung sowie Workshops bei Konferenzen, dass manche Aspekte in Entwicklungsfirmen unzureichend umgesetzt werden. Fragen der agilen Planung überlasse ich einem anderen Artikel, aber eine andere agile Disziplin möchte ich etwas näher beleuchten: das Testen von Software.

Ordentlich testen liefert Qualität

Natürlich würde der Chef niemals zugeben, dass er ungetestete Software ausliefert. Letztlich ist das aber eine Frage der Definition: Schon mal gestartet, rumgeklickt und „ausprobiert“ ist nicht dasselbe wie das sorgsame, systematische und automatisierte Testen einer Software.

„Test-first Development“ bedeutet, dass Entwickler tatsächlich Tests schreiben, bevor sie mit der Implementation einer Funktionalität beginnen. Das ist ein Aspekt der Systematik, der dazu führt, dass Kriterien für die Implementation im Vorhinein festgelegt werden müssen, um sie im Anschluss zu erfüllen. Indem die Tests regelmäßig laufen, sowohl angestoßen vom Entwickler als auch automatisch während des Build-Vorgangs, kann gewährleistet werden, dass Änderungen im Code keine unerwarteten Folgen haben und dass Regressionen frühzeitig erkannt werden.

Gleichzeitig haben diese Tests aber noch eine andere wichtige Rolle: Sie dokumentieren die Erwartungshaltung des Entwicklers während der Implementationsarbeit. Als Grundlage der Anforderungsdefinition dient meist die „User Story“ (gewissermaßen das Pflichtenheft der Neuzeit), aber auf dem Weg zur Implementation haben Entwickler und Team die zuvor beschriebenen Schritte der Abstraktion durchlaufen, ein Verständnis für die Problematik und die Anforderungen des Kunden entwickelt und darauf basierend Implementationsentscheidungen getroffen. Die Tests belegen diese Details, sicherlich nicht in einer für jeden zugänglichen Weise, aber ausreichend zur Klärung jeglicher Zweifel in der Zukunft oder zur Verdeutlichung der Zusammenhänge für andere Programmierer.

Wenn Entwickler gefragt werden, warum die eigene Codebasis noch keine großen Anzahlen automatisierter Tests aufweist, besteht die häufigste Antwort darin, auf den antiken Charakter großer Teile besagter Basis hinzuweisen. „Wir haben heute gar keinen Entwickler mehr, der weiß, wie das geht.“ Dieses Problem ist durchaus verbreitet, wo die Entwicklung schon so lange her ist, dass das Verständnis für die Details der Ausführung fehlt und man allgemein froh ist, dass alles noch „geht“, damit man sich nicht darum kümmern muss. Natürlich weiß man nicht wirklich, ob es geht, denn es gibt keinen besonders verlässlichen Weg, das auszuprobieren. Aber solange die Kunden sich nicht beschweren, wird schon alles in Ordnung sein.

Natürlich gibt es auch Situationen, in denen die Architektur der Anwendung ein automatisiertes Testen schwer oder unmöglich macht. WinForms-Anwendungen mit 30 000 Zeilen Code im Hauptformular? Das ist ein echtes Problem. Dazu kann ich nur sagen: Wer keinen Qualitätsanspruch an das eigene Produkt hat, darf sich von meinen Kommentaren in dieser Kolumne gern ausgeschlossen fühlen. Solche Zustände erfordern drastische Eingriffe, Investitionen in Form von Zeit und Geld letztlich, um ein Produkt dauerhaft pflegbar und damit profitabel zu halten.

Modulare Architekturen machen‘s einfacher

Moderne Architekturen machen Testen einfacher. Im Web setzt sich MVC auf dem Server immer weiter durch, was die Erzeugung von Tests für die Controller vereinfacht. Wichtiger ist allerdings der grundlegende Ansatz der Zustandslosigkeit, den MVC mit Webdiensten teilt. Die Rückbesinnung auf die Tugenden von HTTP als zustandslosem Protokoll zeigt interessante Parallelen zu den Idealen der funktionalen Programmierung oder auch zu den Grundideen von SOA. Je effizienter Sie modularisieren, abstrahieren, Abhängigkeiten verringern und Verantwortlichkeiten definieren, desto einfacherer ist schließlich sowohl die vollständige Architektur eines Anwendungssystems als auch das Testen derselben. Das aktuelle Thema „Microservices“ treibt diesen Ansatz auf die Spitze: Modularisierung ist der Schlüssel, aber nicht wie vor Jahren propagiert vor allem mit dem Ziel der Wiederverwendbarkeit, sondern vielmehr zur Vereinfachung bestehender Strukturen und zur Reduzierung der Werte einzelner Module.

Auf der Seite von Clientanwendungen verbreitet sich zunehmend das MVVM-Pattern, das ebenfalls den Vorteil vereinfachten Testens mit sich bringt. In diesem Fall geschieht das dadurch, dass Code möglichst UI-unabhängig als Bestandteil des View Models implementiert wird und Abhängigkeiten zum UI in diesem Code vermieden werden. MVVM ist ein verbreitetes Schema sowohl auf den XAML-basierten UI-Plattformen der .NET-Welt wie auch in JavaScript-Anwendungen. In der JavaScript-Umgebung gibt es andere verbreitete Libraries wie React und Redux, die ebenfalls durch klare Patterns zur Zustandsverwaltung Einfachheit und Unabhängigkeit im Anwendungscode erzwingen.

Vorteile automatisierter Tests

Die Umsetzung einer klaren Linie für automatisierte Tests ist immer eine Herausforderung. Wenn große Altlasten berücksichtigt werden müssen, ist der Weg entsprechend beschwerlicher. Demgegenüber stehen aber solch gravierende und greifbare Vorteile, dass selbst erhebliche Investitionen einfach zu rechtfertigen sind. Eine umfassende Abdeckung Ihres Anwendungscodes durch automatisierte Tests stabilisiert natürlich in erster Linie diesen Code und vermeidet Regressionen nach der Fehlerbehebung. Gleichzeitig dient die Testbasis allerdings auch als umfassende Dokumentation der implementierten Anforderungen auf einem Detaillevel, der mithilfe unabhängiger schriftlicher Dokumentation kaum zu erreichen wäre. Ihre Entwickler können zuversichtlich mit Fehlersituationen umgehen und notwendige Änderungen durchführen, und solche Arbeiten können in vielen Fällen auch jenen Entwicklern überlassen werden, die nicht die gesamte Codebasis perfekt kennen, da die Absicherung durch die Testbasis jederzeit als doppelter Boden fungiert.

Fazit

In der heutigen Zeit sind Änderung und Neuerung wichtige Aspekte bei der Planung von Softwareprojekten. Vor Jahren wurden solche Projekte geplant, um langfristig Stabilität zu erreichen, heute müssen Sie mit Änderung und Neuerung planen, um längerfristig konkurrenzfähig zu bleiben. Wenn die Codebasis nicht effizient getestet wird oder werden kann, etabliert sich eine Angst vor der Neuerung gleichermaßen bei Programmierern und auf Planungsebene. Mit dem Rückhalt einer ausreichenden Testabdeckung hingegen können Sie auch als Unternehmen agiler sein, auf Anforderungen Ihrer Kunden effektiver reagieren und Neuerungen in der Technologie aufgreifen und von ihnen profitieren.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -