Über unsMediaKontaktImpressum
Finn Lorbeer 02. Februar 2021

Qualität in der Softwareentwicklung

Besser, schneller, stabiler – wie man hochwertige Produkte liefert

Die Frage "Was ist Qualität?" wird oft akademisch, philosophisch oder mit ISO-Definitionen beantwortet. Daher betrachten wir sie einmal am Beispiel eines Produktes, das wir alle kennen: an einem Muffin.

Welche Eigenschaften würden einen Muffin zu einem qualitativ hochwertigen Muffin machen? Sicherlich Schokoladenstreusel oben drauf! Kommen wir direkt zu unserem ersten Vergleich mit der Qualitätssicherung: So wie die Schokolade erst über den fertigen Muffin gestreut wird, so testen wir auch die Qualität von Software erst nach dem Programmieren. Das Problem in beiden Fällen: Es ist keine Schokolade (Qualität) im Muffin (Software).

In diesem Artikel wollen wir uns Methoden und Prozessen zuwenden, die uns zeigen, wir man sich möglichst früh in der Softwareentwicklung um Qualität kümmern kann, oder anders gesagt, wie man die Schokolade direkt in die Muffins einbackt.

Man kann bereits erahnen, dass die unterschiedlichen Methoden und Prozesse das Feld des Quality-Analysten – im Folgenden "QA" – enorm erweitern, so dass wir aus unserer Rolle als "Qualitätssicherung" heraustreten und wahre "Product Quality Specialists" werden.

Wie Veränderungen im Prozess Qualität verbessern

Wenn wir uns die Prozessschritte eines typischen agilen Teams genau ansehen, erkennen wir, was dort im Detail vor sich geht.

Im ersten Schritt (Analyse) planen wir, Wert zu schaffen. Wir schreiben dafür eine Story, die wir dann in einem "Backlog" ablegen, um nichts weiter damit zu tun. Oder anders formuliert: Wir verschwenden Zeit. Im besten Fall ist eine analysierte Story noch aktuell, wenn sie implementiert wird. Oft sind Stories zu dem Zeitpunkt aber schon veraltet. Im nächsten Schritt (Development) fügen wir dann dem Produkt den geplanten Mehrwert hinzu. Danach wartet die Story wieder in einem Prozessschritt "Warten auf QA", also wird auch hier nur Zeit verschwendet. Das Team wartet, bis ein Quality-Analyst (QA) den geplanten Wert überprüft und diesen an die Anwender liefern kann.

Als QA haben wir wenig Einfluss auf die Spalte "Ready for Dev", aber "Warten auf QA" gehört "uns". Und warum sollten wir einen Prozessschritt im Team haben, in dem lediglich Zeit verschwendet wird? Das Entfernen dieser Spalte hat sehr positive Auswirkungen auf Geschwindigkeit und Qualität, wenn wir sie mit einem anderen Werkzeug koppeln: Work in progress Limits. Die Idee lautet wie folgt: Wenn es keine Spalte "Ready for QA" gibt, hat ein:e Entwickler:in keinen Platz, um eine Story abzulegen und eine neue zu beginnen. Daher muss der/die Entwickler:in sicherstellen, dass die Story an eine verfügbare QA übergeben wird. Diese erzwungene Übergabe erleichtert die direkte Kommunikation. Die QA erhält wertvollen Kontext von dem/der Entwickler:in und die Entwickler:in selbst kann mit der QA überprüfen, ob tatsächlich alle Abnahmekriterien einer bestimmten Story erfüllt sind. Dies ist bereits ein großer Gewinn für die Qualität.

Wir haben Limits in verschiedenen Projekten in unterschiedlichen Zusammenhängen angewendet. In einem Fall konnten wir den Zeitraum von "Analyse" bis "Fertig" für Stories von 13 Tagen auf 4 Tage verkürzen, ohne dass jemand "härter" arbeiten musste. Denn weniger Stories im Development erfordern keine ständigen Kontextwechsel. Nacheinander können die Aufgaben schneller abgearbeitet und beendet werden. Die Einschränkung des "Work in progress" wirkt sich positiv auf die Konzentration der Teams aus und somit nicht nur auf die Zeit sondern auch auf die Qualität eines Produktes.

Synergie der Analysten: Wie "Business" und "Qualität" zusammenarbeiten

Um wirklich mit Business-Personen (Business Analyst, Product Owner oder Product Manager) zusammenzuarbeiten, ist es wichtig, alle beteiligten Perspektiven zu verstehen: Unsere Business Analysten (BAs) sind in der Regel sehr darauf bedacht, Software schnell zu veröffentlichen. Denn ein späterer Start eines (Software-)Produkts führt zu höheren Kosten und geringerem Einkommen. Die Aufgabe der QA besteht im Gegensatz dazu, sicher zu sein, dass ein solides und fehlerfreies Produkt auf den Markt gebracht wird. Es geht also darum, die goldene Mitte zwischen Geschwindigkeit und Qualität zu finden. Hierzu hat die NASA einmal aufgeschlüsselt, wo genau die meisten Kosten von Fehlern entstehen (s. Abb. 1).

Es ist leicht zu erkennen, wo die Kosten für Fehler im Bereich der Produktion explodieren. Eine typische erste Reaktion besteht darin, alles noch einmal gründlich zu prüfen, bevor es in die Produktion geht. Dies sind die automatisierten Testfälle in unseren CI/CD-Systemen.

Wenn man das Diagramm genauer betrachtet, erscheint es mir am günstigsten, Fehler frühestmöglich zu beheben und von Anfang an hochwertige Qualität zu liefern. Also während der Analyse und nicht erst während der Tests.

Meiner Erfahrung nach erreicht man das am besten, wenn QAs und BAs tatsächlich nebeneinander sitzen und gemeinsam an Anforderungen arbeiten, die sie dann in kurzen Planungsmeetings dem Team präsentieren. Das Wissen über Anforderungen ("Edge Cases" und "Sad Paths") kann so bereits vor der Implementierung mit dem ganzen Team geteilt werden. Die QAs können sicher sein, dass die wichtigsten "Sad Paths" bereits in der Implementierung berücksichtigt und automatisiert auf Regression getestet werden. Auf diese Weise wird der Aufwand für manuelles Testen erheblich reduziert. So führen wir – im Gegensatz zum Code-Freeze-Test unter Zeitdruck – unsere Produkte früher bei gleichzeitig deutlich besserer Qualität auf dem Markt ein.

Sei proaktiv

Idealerweise arbeitet man gemeinsam mit den Entwickler:innen daran, die Regressionstest von Unit- bis End-to-End nach der Testpyramide zu strukturieren. Allerdings ist es ganz egal wie ausgeklügelt man diese Tests gestaltet, sie werden immer erst nach der Implementierung ausgeführt.

Um Qualität von Anfang an zu erhöhen, versuchen wir in allen Teams eine einfache Regel anzuwenden: Jeder Commit geht nach Produktion. Dies bringt ein paar Vorteile mit sich:

Wenn man diese Regel festlegt, erhöht sich die Qualität jedes einzelnen Commits. Denn sobald QAs nicht mehr die letzten Wächter über mögliche Fehler sind, verwenden Entwickler:innen mehr Zeit darauf, sicher zu stellen, dass ihre Tests die wichtigsten Dinge abdecken. Und da QAs die Experten für Tests sind, wird die Push-and-Pull-Beziehung zwischen Entwickler:innen und QAs durch diese neue Regel umgekehrt: Bislang wurden Tickets zu den QAs gepusht, um getestet zu werden. Nun bitten Entwickler:innen, während und insbesondere auch vor der Implementierung um Beratung durch die QAs, wie sie die Tests am besten strukturieren.

Ein zweiter großer Vorteil ist, dass man in Notfällen deutlich handlungsfähiger ist. Normalerweise hat man im klassischen Releasemanagement einen komplizierten Plan, wie ein Release durchgeführt wird. Falls etwas schief geht, gibt es einen Hotfix-Cherry-Pick-Branch-Release-Prozess, der die meisten  Sicherheitsmaßnahmen und Qualitätssicherungen umgeht. Das klingt nicht besonders vertrauenserweckend.

In unseren Team-Setups brauchen wir das nicht mehr. Mit Release-Zyklen von 30 Minuten oder weniger können wir sehr schnell ohne Hotfixes oder Branches auf Probleme in der Produktion reagieren.

Die wirklich interessante Frage ist dann wie man das Monitoring so gestaltet, dass man Probleme früher findet. Dies enthält mindestens die Visualisierung der Fehleranzahl sowie der Server-/Datenbankenantwortzeiten. Wenn man auf ein wirklich professionelles Niveau möchte, kann man über die vollautomatisierte Erkennung von Anomalien nachdenken.

Dadurch haben wir deutlich weniger Probleme mit den Releases, während wir neue Funktionen auf sehr kontrollierte Weise mit Hilfe von Feature Togglen aktivieren. So liefern wir nicht nur schnell neuen Wert für unsere Anwender, wir erreichen gleichzeitig auch höhere Qualität.

Wie eine vertrauensvolle Fehlerkultur den ultimativen Qualitätsboost bringt

Jedes Team macht Fehler, das ist menschlich und gut, denn aus Fehlern lernen wir. Da QAs sich außerordentlich viel mit dem Risiko und Einfluss von Fehlern beschäftigen, können sie dem Team helfen, in einer sicheren Umgebung schnell Fehler zu machen – und somit schnell zu lernen. Das wiederum erhöht nicht nur die Sicherheit und das Vertrauen im Team sowie die Qualität der Software, sondern fast nebenbei auch das Innovationspotential des Teams.

Eine Methode, die wir sehr intensiv einsetzen – und als QAs vom Team einfordern – ist das Pair Programming. Es hilft uns insbesondere kleine Flüchtigkeitsfehler zu vermeiden, den Klassiker sozusagen. Es gibt wahrscheinlich 100 von ihnen in diesem Artikel. Eine effiziente Schadensminderung ist das "pairing" von zwei Personen, meist Entwickler:innen.

Flüchtigkeitsfehler sind allerdings nicht die einzige Motivation zum Pairing. Kennen Sie den "Aha-Moment", den man hat, sobald man etwas einfach mal ausprobieren kann und dadurch versteht, wie etwas funktioniert? Wir versuchen es dem Team möglichst leicht zu machen, solche Momente durch "ausprobieren" (= gezielt Fehler provozieren) zu erleben.

Zu guter Letzt gilt es noch sicherzustellen, dass Ihr Team Spaß hat! "Spaß", werden Sie fragen – "wirklich?"

Ja! Stellen Sie sich zwei verschiedene Teams vor. In einem Team sind die Menschen sehr begeistert. Sie kommen glücklich zur Arbeit und begrüßen sich am Morgen. Sie kommunizieren und teilen miteinander, woran sie arbeiten, wie und warum. Dann gibt es ein anderes Team, bei dem die Leute es vorziehen, morgens eine To-Do-Liste zu erhalten und ansonsten in Ruhe gelassen zu werden. Was glauben Sie, welches Team ein besseres Produkt bauen wird? Welches Team wird am Ende weniger Fehler machen? Welches Team wird eher eine Deadline halten?

Quality Specialists sind in der Regel das Verbindungsstück zwischen Entwickler:innen und den Fachbereichen. Wir verbinden die Menschen und deren Perspektiven. Das hilft beim Aufbau einer vertrauensvollen Kultur. Es sind die kleinen Dinge, die eine großartige Kultur ausmachen. Und wir Quality Specialists sind normalerweise mittendrin.

Durch die Kombination einer positive Teamatmosphäre mit einer starken Zusammenarbeit von QA und BA sowie einer exzellent geformten Testpyramide und einem Prozess, der hilft Software schnell nach Produktion zu bringen, werden Sie und Ihr Team letztendlich stärker, schneller und solidere Produkte in höherer Qualität liefern – auch wenn es "nur" Muffins sind!

Autor

Finn Lorbeer

Finn Lorbeer ist Product Quality Specialist. Qualitativ hochwertige Software ist ihm ein Herzensanliegen. Manchmal analysiert er Business-Anforderungen seiner Kunden und manchmal Team-Zusammenstellungen und deren Prozesse.
>> Weiterlesen

Kommentare (0)

Neuen Kommentar schreiben