„Ich werde hellhörig, wenn es heißt: Das muss nur noch getestet werden.“

Daniel Gehrke: Ich ziehe ganz gerne die Analogie zum TÜV. Den TÜV kennen wir alle als die, die uns alle zwei Jahre bei den Autos ärgern. Man sieht aber gar nicht so richtig, dass der TÜV ja noch viel mehr macht.

Wenn ich als Autohersteller ein neues Bremssystem auf den Markt bringen möchte, dann baue ich das ja auch nicht fertig und sage am Ende: ‚So, lieber TÜV, jetzt setzt euch doch mal rein und guckt, ob das Ding wirklich bremst.‘ Sondern man stellt von Anfang an Richtlinien auf, welche Bedingungen für ein Bremssystem erfüllt werden müssen und testet erstmal auf einem Prüfstand.

Das Gleiche machen wir als QS in der Softwareentwicklung. Wir sind von Anfang an dabei und geben Richtlinien vor, wie die Qualität eingehalten werden muss und wie die Komponenten getestet werden. Und zwar von allen, nicht nur von uns.

Kemalettin Oguz: Qualität spielt von Anfang bis Ende eine zentrale Rolle. Manche haben das Bild vor Augen: ‚Dann testen wir es eben am Ende ganz schnell.‘ Aber es beginnt schon ganz am Anfang bei den klaren Anforderungen und zieht sich konsequent bis zum Ausliefern des Produktes. Nur wenn Qualität frühzeitig mitgedacht wird, lässt sich ein verlässliches und nachhaltiges Ergebnis erzielen.

Daniel Gehrke: Wir machen Qualitätssicherung, um Risiken zu minimieren. Zum Beispiel das Risiko, dass jemand beim Programmieren einen Fehler macht oder dass sich der Kunde falsch ausgedrückt hat. Menschen machen Fehler.

Es gibt Produktrisiken, die mit unserer Software zusammenhängen. Es gibt aber auch Projektrisiken, die das Umfeld betreffen: Haben wir die passenden Leute, die das Ganze umsetzen sollen? Ist das Budget korrekt? Sind unsere Vorgehensweisen wie Scrum oder das Wasserfallprinzip passend? Auch darauf achten wir.

Damit wird deutlich, dass QS von Anfang an dabei sein muss. Beim Hausbau muss ich ja auch gucken, ob das Fundament richtig gegossen wurde. Ich kann nicht am Ende ein wackelndes Haus haben und sagen: ‚Ja, stimmt, das Fundament war damals auch doof.‘

Kemalettin Oguz: Auch das wird durch das Projekt vorgegeben. Es gibt Projekte, die arbeiten mit sensiblen Daten, da sind die Themen Datenschutz und Sicherheit relevant. Es gibt Projekte, die sehr performant laufen müssen, weil sie eine hohe Nutzerlast haben. Da müssen gewisse Last- und Performance-Testszenarien gebaut werden. Es gibt Projekte, bei denen beides weniger relevant ist – dort rücken andere Qualitätskriterien in den Vordergrund. Entscheidend ist es also, die Tests an die Anforderungen des Projektes anzupassen.

Kemalettin Oguz: Genau. Bei jedem Projekt gilt, dass die Kundenanforderungen geprüft werden müssen: Was ist am Ende wirklich nutzbringend für ihn? Dieses Paket muss auf jeden Fall funktionieren. Darüber hinaus sind es individuelle Anpassungen, die projektabhängig sind.

Daniel Gehrke: In der ISO 25010 steht, was alles zur Softwarequalität gehört. Es gibt funktionale Anforderungen, also Dinge, die die Software tun soll. Und es gibt nicht-funktionale Anforderungen: Wie schnell macht sie das? Wie gut sind Performance, Effizienz, Benutzbarkeit, digitale Barrierefreiheit, Sicherheit oder Portabilität?

Das hängt stark davon ab, was wir entwickeln. Es gibt Anwendungen, wo Portabilität wichtiger ist als anderswo. Eine Handy-App, die muss auf allen möglichen Handys laufen. Wenn die Anwendung nur in einem Browser im Unternehmen laufen soll, dann ist das nicht so wichtig.
 

Daniel Gehrke: Das ist ein gerne genanntes Schlagwort. Die Vorstellung ist immer cool: Wir automatisieren die Tests, dann brauchen wir nichts mehr zu tun. Tatsächlich ist es aber so: Eine Software lebt und wird verändert. Auch die Tests müssen angepasst werden. Wenn ich eine Automatisierung schreibe, dann baue ich auch eine Software. Für die Entwicklung der automatisierten Tests muss ich mir die gleichen Gedanken machen, wie für jede andere Softwareentwicklung auch.

Es gibt verschiedene Ebenen, auf denen ich automatisieren kann. Die einfachsten Tests sind Komponenten-Tests während der Entwicklung. Die machen wir immer. Da werden große Teile des Codes isoliert vom Rest des Systems getestet. Dann gibt es Schnittstellentests – immer da, wo irgendwelche Sachen miteinander kommunizieren. Also zum Beispiel die Datenbank mit meiner Anwendung. Aber auch mein Online-Shop mit PayPal. Und dann gibt es ganze Business Cases, die ich von Anfang bis Ende durchtesten kann.

Das könnte ich alles automatisieren. Das ergibt dann Sinn, wenn eine Entwicklung über einen längeren Zeitraum mehrere Iterationen hat. Da möchte ich wissen: Wenn ich an einer Stelle etwas anfasse, was mache ich dabei woanders vielleicht kaputt? Automatisierung ist kein Allheilmittel. Doch mit Automatisierung kann ich in kürzerer Zeit und kontinuierlich testen.

Kemalettin Oguz: Gerade bei Tests, die wiederkehrend sind, bietet sich eine Automatisierung hervorragend an. Das sind beispielsweise Regressionstests oder Smoke-Tests, die bei einem Projekt, das länger läuft, immer wieder durchgeführt werden müssen. Automatisierte Tests nehmen hier Arbeit ab und sorgen für Sicherheit, wenn es nicht allzu viele Änderungen im Laufe des Projekts gibt. Besonders in Bereichen, die ein gewisses Risiko bergen, wie ein Zahlungsprozess, der in einem gewissen Zyklus abgetestet werden soll.

Daniel Gehrke: Es gibt Fehler im Prozess. Zum Beispiel wenn Leute meinen, sie hätten die Anforderungen richtig aufgeschrieben, da brauche keiner mehr draufzugucken. Wir stellen häufig fest, dass Kund:innen sich das Ergebnis am Anfang ganz anders vorgestellt haben. Dann sieht man es umgesetzt und sagt: ‚So ist das gar nicht praktikabel.‘

Und es gibt Fehler in Produkten. Immer mal wieder kommen Designfehler vor. Irgendwas wird in Browsern nicht richtig angezeigt oder nicht ganz so umgesetzt wie in der Vorlage. Häufig wird an den Standard-Fall gedacht, aber nicht an den Grenzfall. Wenn wir sagen: Wir versichern Erwachsene ab 18 bis 65 Jahren – was heißt das denn ganz genau? Der Geburtstag um 23:59 Uhr? Die genaue Geburtszeit? Und in welcher Zeitzone?

Kemalettin Oguz: Die häufigsten Befunde sind Darstellungsfehler. Es gibt auch Systeminfrastrukturprobleme: Etwas funktioniert auf einer Testumgebung einwandfrei, nach dem Deployment auf der Produktivumgebung aber nicht mehr, weil dort die Rahmenbedingungen anders sind.

Daniel Gehrke: Eins meiner Lieblingsbeispiele ist ein Paket-Logistiker, bei dem wir Tests durchgeführt und entdeckt haben, dass Millionen von Paketen falsch abgerechnet worden wären. Und beim selben Kunden wurde durch Monitoring, also durch Beobachten der laufenden Produktionsumgebung, ein Hacking-Angriff entdeckt und verhindert. Da wären sonst tausende Kund:innen mit Spam belastet worden.

Wir haben außerdem festgestellt, dass einmal fast die gesamte Produktion stehen geblieben wäre. Man kann sich vorstellen, was bei großen Paket-Logistikern passiert, wenn die einen Tag lang ihre Pakete nicht verschicken können, weil durch ein Software-Update auf einmal alle Scanner nicht mehr funktionieren.

Kemalettin Oguz: Bei der Ticketverkaufsplattform eines Sportvereins war die Umgebung nicht mal ansatzweise so stabil, dass das neue System die durchschnittliche Anzahl der bisherigen User:innen aushalten konnte. Da mussten wir erheblich nachbessern, was die Performance und die Lasteigenschaften angeht. Wenn wir ohne Lasttest live gegangen wären, dann hätten die Leute wahrscheinlich keine Tickets kaufen können, weil das System eingestürzt wäre.