Das Richtige richtig tun – Qualitätsaspekte moderner Software-Entwicklung

Was für einfache Webseiten vor vielen Jahren noch einfach beherrschbar war, ist mit modernen Anwendungen der heutigen Zeit nicht mehr zu vergleichen. Software-Entwicklung hat sich verändert: Das in sich geschlossene, leicht überschaubare Projekt ist dem Zusammenspiel verschiedenster vernetzter Komponenten gewichen. Mit dem Siegeszug der schnellen Internetverbindungen, Always-on-Konnektivität und Cloud-Lösungen arbeiten verschiedene Komponenten aus verschiedenen geographischen und organisatorischen Orten wie ein präzises Uhrwerk zusammen, um den Anwender*innen die Funktionen möglichst intuitiv und performant zu ermöglichen. Dahinter stecken verschiedene Cloud Services, Datenbanksysteme, Bibliotheken und Frameworks. So praktisch es ist, vorhandene Frameworks für Teillösungen zu benutzen, so wichtig ist hier allerdings auch die sichere und verlässliche Einbindung in die eigenen Software-Systeme. In vielen Fällen stammen die einzelnen Komponenten von unterschiedlichen Entwickler*innen mit möglicherweise unterschiedlichem Herangehen ans Entwickeln und Management der Qualität. Fällt ein Baustein aus oder erzeugt einen Fehler, bedroht dies die Verlässlichkeit und Stabilität der gesamten Anwendung. Schnell wird klar, dass das Verständnis von Qualität und wie sie das Entwicklungsteam sicherstellt, mehrere Dimensionen umfasst.

Interne und externe Qualität

Offensichtlich und spontan erlebbar wird die externe Qualität von Software aus Nutzersicht. Tut sie was sie tun soll? Läuft sie stabil? Dazu zählt auch das Fehlerverhalten oder zum Beispiel wie die Software auf eine Fehlbedienung durch den Benutzenden reagiert. Aber auch technische Umstände müssen berücksichtigt werden. Besteht beispielsweise die Gefahr, dass die Datenbankverbindung ausfällt, weil ein Endgerät das WLAN-Netz verliert, kann die Anwendung aufhören zu arbeiten, im ungewollten Fall auch abstürzen. Eleganter wäre es hier, über ein abgesichertes Verhalten bei (temporären) Offline-Situationen nachzudenken.

Aber Qualität ist viel mehr als nur die Abwesenheit von Bugs. Neben der Richtigkeit der Funktionalität zählen noch viele nicht-funktionale Kriterien dazu. In dem in der ISO 25010 verankerten Leitfaden für Software-Systeme “Software Product Requirements and Evaluation (SQuaRE)” werden relevante Richtlinien zur Qualität von Software und Software-Entwicklung im Detail erläutert. Dies führt uns zu der internen Perspektive von Software-Qualität.

Der menschliche Aspekt bei der Entwicklung und Wartung von Software ist uns sehr wichtig. Sollten Sie unseren ersten Artikel der Serie über unser Verständnis von Software Engineering verpasst haben, verweisen wir gerne nochmal auf diesen. Menschen entwickeln mit Menschen Software für Menschen – da wird Zusammenarbeit wichtig, entweder direkt beim gemeinsamen Entwicklen im Team (oder in einem gemeinsamen Team mit unseren Kunden) oder bei der späteren Weiterentwicklung von Software nach einer gewissen Zeit. Interne Qualität bedeutet zum Beispiel:

  • Developer Experience / Wartbarkeit: Wie wird Software gebaut und dokumentiert? Wie ist sie wartbar? Finden sich Entwickler*innen schnell zurecht oder brauchen sie lange zur Einarbeitung?
  • Portierbarkeit: Bei der Vielzahl an Geräten und Konfigurationen: Auf welchen der vielen Varianten möchten wir die Software laufen haben? Gibt es zukünftige Erweiterungen oder neue Plattformen?
  • Kompatibilität: Mit welchen Systemen über welche Schnittstellen soll die Software zusammenarbeiten?

Ist Qualität verhandelbar?

Gibt es die “Silver Bullet” – eine allgemein gültige Antwort? Legt man den zentralen Aspekt von externer Softwarequalität zu Grunde, wird es schwierig, hier Kompromisse zu schließen. Software muss das tun, wofür sie erschaffen wurde und darf nicht durch Bugs oder Instabilitäten die eigentlichen Aufgaben in Frage stellen. Hier sprechen wir von einem Mindestmaß an Qualitätskritierien, ohne die bei XITASO kein Release das Haus verlässt. Gehen wir im Verständnis von Qualität aber weiter und bewerten auch die Aspekte, die wir im vorangegangen Absatz beschrieben haben, wird klar, dass zusätzliche, im ungünstigsten Fall ungeplante Maßnahmen Entwicklungsaufwand und damit Kosten bedeuten. Beim Beispiel des Verbindungsabbruchs zur Datenbank von vorhin gibt es verschiedene Ausprägungen von Sicherheitsmaßnahmen. Das Problem mit einer Fehlermeldung zu behandeln, wäre noch relativ geringer Aufwand, allerdings mit geringer Nutzerzufriedenheit. Einen Offline-Modus zu konzipieren und in der Entwicklung umzusetzen, ist mehr Aufwand und kann im Requirements Engineering dementsprechend geplant und bewertet werden. Mehr Aufwand bedeutet hier mehr Stabilität und, aber auch einen ganz neuen Mehrwert für die Anwendung.

Wie wird so etwas denn entschieden, fragen Sie sich vielleicht jetzt. Gemeinsam ist die Antwort. Unser Verständnis als High-End Software Engineering Dienstleister ist es, zusammen mit unseren Kunden genau solche Fälle zu besprechen und im besten Fall früh im Prozess zu planen. Die Entscheidung, wie es dann gelöst wird, fällt dann zu einem Zeitpunkt, bei dem keine unerwarteten, zusätzlichen Kosten für Neuplanung, Rewriting oder Änderung von Architekturen im Nachhinein anfallen. Diese Abstimmungen auf Augenhöhe sind unser Verständnis von höchster Qualität, auch im erweiterten Verständnis.

Mit lebendigen Prozessen zum digitalen Erfolg

Wir leben jeden Tag das Agile Mindset, so dass der transparente, regelmäßige Austausch zum Beispiel in den Daily Standup-Meetings oder bei Retrospektiven Teil unserer DNA ist. Speziell für die Software-Entwicklung gibt es einige Methoden und Arbeitsweisen, mit denen wir konkret Qualität sicherstellen. Hier eine Auswahl:

Sprint Review

In regelmäßigen Abständen (i.d.R. zwei Wochen) begutachten der Kunde, das Entwicklungsteam und idealerweise auch erste Endanwender*innen den aktuellen Entwicklungsstand. Durch diese enge Abstimmung wird das gemeinsame Verständnis über die zu entwickelnde Software stets verbessert.  Das in diesem Meeting geäußerte Feedback (und gerne auch Kritik) fließt direkt in die folgende Projektplanung ein und erlaubt somit dem Auftraggeber auch während des Projektverlaufs Kursänderungen vorzunehmen.

Code Review

Jede Änderung am Source Code wird bei uns von mindestens vier Augen gesehen. Dadurch können Qualitätsprobleme am Code früh identifiziert und ausgeräumt werden. Zudem wird vermieden, dass sich “Wissensinseln” bilden, da über jede Änderung mindestens zwei Personen Bescheid wissen. Unsere Teams führen Reviews i.d.R. Tool-gestützt durch. Dadurch wird sichergestellt, dass keine Änderung übersehen wird und es ist für jeden ersichtlich, wer eine Änderung gereviewed hat.

Pair Programming

Zwei Entwickler an einem Bildschirm – was auf den ersten Blick ineffizient aussieht, hat sich in der Praxis oft bewährt. Gerade bei komplexen Fragestellungen hilft es, diese zu zweit zu besprechen und zu lösen. Hierbei können auf kurzem Weg Lösungsmöglichkeiten diskutiert und ausprobiert werden. Das vier Augen Prinzip wird automatisch erfüllt, weshalb ein formales Code Review danach oft nicht mehr nötig ist. Zudem ist Pair Programming ein sehr gutes Werkzeug, um das gemeinsame Verständnis über den Code zu stärken und neue Entwickler*innen mit der Code-Basis vertraut zu machen.

Manuelle Tests

Da die meiste Software, die wir entwickeln, von Menschen benutzt wird, ist es auch wichtig, dass auch ein Mensch die Software begutachtet. Während viele repetitive Aufgaben von automatisierten Tests erledigt werden, konzentriert sich der manuelle Test vor allem auf Fragestellungen, die sich mit automatisierten Tests nur schwer beantworten lassen. Ein paar Beispiele:

  • Ist das, was am Bildschirm zu sehen ist, verständlich?
  • Ist die Benutzeroberfläche korrekt oder gibt es Probleme (z. B. ein verschobenes Layout)
  • Ist die Software auf allen geforderten Bildschirmgrößen benutzbar?
  • Kann ich mit der Software zügig und unproblematisch meine Aufgabe erledigen?

Aber es geht auch automatisiert.

Automatisierte Tests

In der modernen Software-Entwicklung setzen wir sehr stark auf automatisierte Tests. Dies hat vor allem zwei Vorteile:

  • Geschwindigkeit: Ein Computer kann mehrere tausend Testfälle in wenigen Minuten durchführen.
  • Wiederholbarkeit: Ein Computer führt die Testfälle bei jedem Lauf exakt gleich aus.

Diese Vorteile ermöglichen uns sehr kurze Feedbackschleifen, da in der Praxis diese Tests sehr viel häufiger ausgeführt werden als es beim manuellen Testen überhaupt möglich wäre. So bekommt ein*e Entwickler*in bereits auf der eigenen Workstation mit, wenn eine Änderung unbeabsichtigt eine bestehende Funktion beeinträchtigt und kann das Problem direkt beheben.

Aber auch bei der Fehlerbehebung (“Bugfixing”) ist Testautomatisierung ein wertvolles Werkzeug. Bevor wir den eigentlichen Fehler beheben, erstellen wir einen Testfall, der genau diesen Fehler auslöst. Dieser schlägt natürlich fehl, da die Software den Bug noch enthält. Anschließend wird der eigentliche Fehler behoben und der Testfall zeigt sogleich den Erfolg der Maßnahme an. Der so erstellte Testfall stellt nun sicher, dass der Fehler durch eine spätere Änderung nicht wieder auftritt.

Sprint-Retrospektive im Team

Nie stehen bleiben und sich stetig zu verbessern ist Teil unserer DNA. Genau dies leben wir in unseren Sprint-Retrospektiven. Hierbei blicken wir auf den vergangen Sprint zurück, benennen Erfolge und Rückschläge und identifizieren Verbesserungspotenzial. Anschließend definieren wir spezifische Maßnahmen, die wir im kommenden Sprint durchführen, um die identifizierten Potenziale auszuschöpfen. Sprint-Retrospektiven sind somit ein wesentlicher Bestandteil unserer Feedback-Kultur und ein wichtiger Treiber unseres Erfolgs!

Projekt-Retrospektive mit Kunden

Ein Projekt kann nur erfolgreich sein, wenn die Zusammenarbeit zwischen den verschiedenen Stakeholdern funktioniert. Unterschiedliche Erwartungshaltungen können hier schnell zu Missverständnissen führen. Deshalb sind auch auf dieser Ebene Retrospektiven wichtig, um ein gemeinsames Verständnis dafür zu schaffen, wie das Projekt gestaltet werden muss.

Und noch etwas XITASO spezifisches: der Projektmonitor

In diesem projektbezogenen Dashboard bewerten wir zusammen mit dem Kunden sprintweise die Projektrisiken bezogen auf Ausrichtung, Technologie, Zusammenarbeit, Kosten und Zeitplan.