Built-in Quality: Eine Frage der Business Analyse

Diesmal zu Gast in meiner Built-in Quality Interview-Serie ist Christoph Zuber, seines Zeichens Business Analyst, Product Owner und Requirements Engineer. Je nach Projekt findet man ihn auch in verschiedenen Testing-Rollen. 

Pia: 

Herzlich willkommen, Christoph! Es freut mich sehr, dass du dir heute Zeit nimmst, mit mir über Softwarequalität und Built-in Quality zu plaudern. 

Stell‘ dich bitte kurz vor. 

Christoph: 

Ich bin Christoph Zuber und seit gut 7 Jahren als Business Analyst bei Zühlke tätig. Hierbei bin ich in Rollen unterwegs, in welchen ich verschiedene Stakeholder:innen zusammenbringe. Oftmals sind das Fachvertreter:innen. Ich übersetze Anforderungen der Fachvertreter:innen so, dass Software Entwickler:innen etwas Passendes bauen können. Oft bin ich in Aktivitäten involviert, bei welchen es darum geht zu prüfen, ob das, was gebaut wurde, auch das ist, was verlangt wurde. Bei derartigen Aktivitäten hatte ich meine ersten Touchpoints mit Testing. 

Ich denke Testing passt gut zur Business Analyse, denn Qualität hängt immer davon ab, wer die Software am Ende benutzt. Was sind die Bedürfnisse der Benutzer:innen? Was ist das Business dahinter? Als Business Analyst ist es meine Aufgabe, diese Bedürfnisse zu verstehen und entsprechend zu formulieren. Im Nachhinein kann ich so prüfen (testen), ob das Gebaute mit dem Geforderten übereinstimmt. Ein solcher Test ist eine Art der Anforderungsanalyse. Einfach zu einem anderen Zeitpunkt und aus einer anderen Perspektive.

Vor meiner Zeit als Business Analyst habe ich für einige Zeit Software auf dem Mainframe entwickelt. Auch wenn das weit weg von den heutigen, modernen Technologien ist, hilft mir diese Erfahrung zu verstehen, was Software Entwickler:innen brauchen und wie ich meine Anforderungen am Besten formuliere, sodass sie schnell verstanden werden. 

Pia:

Vielen Dank, Christoph. 

Wir beide haben uns Anfang 2019 bei Zühlke im sogenannten Topic Team (= Community of Practice) Softwarequalität kennengelernt. Ausserdem hatten wir in den letzten Jahren zwei Mal das Vergnügen in konkreten Projekten zusammenzuarbeiten. 

Christoph:

Das waren zwei wirklich spannende Projekte, bei denen Qualität ein grosses Thema war.

Das erste war eine „Feuerwehrübung“, wo man kurz vor dem Release gemerkt hat, dass man keine Ahnung von der Qualität hat und dringend Hilfe braucht. Im zweiten Projekt haben wir uns um eine Software gekümmert, die sehr lange gewachsen war. Auch hier war die Qualität über den ganzen Prozess hinweg bis zu dem gelieferten Produkt nicht überzeugend. 

Pia:

Ja, genau. Das bringt mich gerade zur Frage: Was bedeutet Softwarequalität für dich? Was ist deine Definition von Built-in Quality?

Christoph:

Für mich ist das Wichtigste bei Built-in Quality, Überraschungen zu vermeiden. Softwareentwicklung ist per se ein komplexer Prozess. Sehr kreativ, viele unbekannte Variablen, die involviert sind. 

Bei Built-in Quality geht's darum, dass das, was man gebaut hat, gut genug ist, um nicht später auf etwas zurückkommen zu müssen, wo man denkt, das hatten wir doch schon erledigt.

Eine Funktion zu bauen ist das eine, aber die Zeit, die du brauchst, um dich wieder in den Kontext zu denken, wird immer mehr, je weiter du vom Thema weg bist. Deshalb ist es effizienter, eine Funktion wirklich sauber abzuschliessen, als mal etwas hinzuwerfen und es dann später sauber zu machen und Fehler zu flicken.

Für mich heisst Built-in Quality, dass wir, wenn wir etwas bauen, nicht nur schauen, dass einfach mal was da ist, sondern, dass wir sicher sind: es entspricht den Anforderung und es hat die nötige Qualität für unsere Benutzer:innen und für unser Business. Dafür müssen wir natürlich wissen, was unser Business ist, wer die Benutzer:innen sind, was deren Anforderungen sind und was Qualität in diesem Kontext bedeutet. 

Einerseits bedeutet Qualität sicherlich, ob die funktionalen Anforderungen erfüllt sind. Andererseits gibt es auch nicht-funktionale Anforderungen wie z.B. Performance. Diese sind sehr kontextabhängig und gehen leider oft unter. Plötzlich ist man produktiv, mit echten User:innen auf der Applikation und merkt, dass die Reaktionszeit unbrauchbar ist. 

Das sind Themen, an welchen ich als Requirements Engineer beteiligt bin. Wie kläre ich solche Anforderungen im Voraus? Und wenn wir die Anforderungen definiert haben, wie testen wir, ob sie erfüllt wurden? All das spielt in Built-in Quality. Relevante Themen müssen von Anfang an berücksichtigt werden. Qualität später hinein testen geht nicht!

Pia:

Hast du das immer schon so gesehen? 

Christoph:

Sicher nicht. Die ersten Erfahrungen bei einer Bank waren noch sehr Wasserfall. Man hatte die Entwicklungsphase. Da wurde entwickelt. Vielleicht hatte man da mal davon gesprochen, dass Entwickler:innen Unittests machen, aber richtig verstanden haben wir es zu dieser Zeit nicht. Dann kam die Testphase, in der jemand anderes die Lösung getestet hat. Das war immer schwierig, weil unsere Tester:innen gar nicht verstanden haben/nicht verstehen konnten, was wir gebaut hatten. Ich habe viel Zeit damit verbracht zu erklären, was wir gebaut haben und damit leider auch die Tester:innen beeinflusst, sodass sie die kritische Distanz verloren haben. 

Heute arbeiten wir viel agiler. In jedem Sprint werden Features bzw. Stories abgeschlossen. Da gibt es eigentlich keinen Code-Freeze und keine nachgelagerte Testphase. Hier möchte ich schnelles Feedback. Testen findet im Team statt. Der/die Tester:in bietet einen Service im Team. Sobald jemand etwas so weit programmiert hat, um es zu testen, kann ein/e Tester:in für einen Vier-Augen-Check hinzugezogen werden. Diese Person gibt kritisches Feedback und bringt eine andere Perspektive ein. 

Pia:

D.h. auch in einem agilen Team siehst du „Tester:in“ als eine wichtige Rolle? Ist es nötig, eine eigene Person dafür im Team zu haben? 

Christoph:

Ja. Das Schwierige beim Testen ist, die kritische Distanz zu wahren. Eine Vision für neue Features zu entwickeln ist ein anderer Denkmodus, als kritisch zu hinterfragen, wie etwas funktioniert und (Test)Szenarien zu entwickeln. Es ist schwierig, gleichzeitig visionär vorauszudenken, Lösungen gut zu verkaufen, kritisch zu sein und sich selbst zu hinterfragen.

Deshalb lohnt es sich, aus meiner Sicht, jemanden explizit für das kritische Denken zu haben. Diese Person muss nicht jedes Feature, nicht jede Story testen. Aber bei den wichtigen Punkten bringt so jemand noch mal eine andere Perspektive ein und hinterfragt.

Pia:

Ja, absolut. Oftmals geht das verloren. Wir möchten möglichst schnell etwas Cooles auf den Markt bringen. Der kritische Blick auf unser cooles „Baby“, den mögen wir nicht so gern und blocken ihn deshalb auch oft als „negativ“ ab. 

Christoph:

Kritisieren hat ja auch etwas Negatives. 

Das ist die Schwierigkeit in der Quality-Rolle. Man ist schnell in der Situation, wo man seine Teamkolleg:innen kritisiert. Das Ziel ist aber, nicht die Person, sondern das Resultat kritisch zu hinterfragen und Probleme zu erkennen. Jede/r professionell Denkende ist froh um konstruktives Feedback. Nobody is perfect! Natürlich sollte Kritik immer entsprechend (wertschätzend) formuliert sein.

Scrum begünstigt das Denken, Story um Story abzuschliessen. Im meinem aktuellen Projekt haben wir gerade leider die Unsitte, dass man am Ende des Sprints alle Stories schliessen will. Man schliesst dann lieber eine noch nicht sauber getestete Story oder noch schlimmer, eine Story bei welcher nicht alle Akzeptanzkriterien eingebaut sind, um den Sprint abschliessen zu können. Es geht nur um, „wir haben es in diesem Sprint eingeplant, wir müssen es in diesem Sprint abschliessen“. Das ist genau nicht mein Verständnis von Built-in Quality. Built-in Quality heisst für mich, wir schliessen die Story erst, wenn wir wissen, es funktioniert zuverlässig und wir haben es getestet. Wir arbeiten als Team noch daran, das gleiche Verständnis zu haben. Korrigieren müssen wir sowieso, falls etwas nicht funktioniert. Das machen wir dann aber losgelöst. Wenn wir unfertige Stories abschliessen, geben wir uns der Illusion hin, schnell voranzukommen, bauen aber de facto ein Backlog an Bugs auf. 

Pia:

Wie gehst du als Product Owner damit um, wenn dein Team nicht alles liefern kann, wozu es sich committed hat? (Alles zu liefern würde Abstriche bei der Qualität bedeuten.)

Christoph:

Das ist immer eine Frage der Priorisierung. Es gibt ein Backlog mit einer Reihenfolge. Manchmal gibt es natürlich externe Abhängigkeiten und harte Deadlines. 

Im aktuellen Projekt wäre es eigentlich einfach. Niemand wartet auf uns, aber es gibt eine Deadline in 2 Jahren. Bis dahin sind wir relativ frei. Aus meiner Sicht können wir es uns leisten, die Qualität sauber zu machen. Dennoch können wir nicht alles vergolden. Wir haben eine Menge Funktionalitäten umzusetzen. Man muss abwägen, ob etwas gut genug ist, um damit Feedback einzuholen. Wir wollen unsere User:innen nicht verärgern. 

Pia:

Was ist deine konkrete Rolle im aktuellen Projekt?

Christoph:

Ich bin einerseits Business Analyst. Ich unterstütze den PO das Backlog zu planen, Features und Stories zu erarbeiten. Ausserdem unterstütze ich den PO in strategischen Themen.

Andererseits habe ich eine Quality-Rolle. Ich koordiniere das Testing für unser Team. Im Moment teste ich auch selber sehr viel. Wir sind aber dabei, einen Automatismus aufzubauen, der unser Testing vereinfacht. Wir möchten einen wichtigen Aspekt des Produkts, nämlich gute Datenqualität, so weit wie möglich automatisiert testen können. Hierfür bauen wir gerade ein Testset auf. 

Ein Testset aufzubauen heisst einerseits, dass du alle kritischen Fälle abdeckst, es muss also relativ breit sein. Andererseits soll es wartbar und schnell sein. Es darf also nicht zu gross sein. 

Pia:

Spannend und sicher nicht einfach. Du bist in einer Doppelrolle mit eben diesen beiden unterschiedlichen Fokussen. 

Christoph:

Ja, es ist manchmal wirklich schwierig, den mentalen Fokus richtig zu verteilen. 

Pia:

Ein gutes Testset sollte meines Erachtens risikobasiert sein. Allerdings habe ich in der Vergangenheit vor allem von Product Owner:innen oder Business Analyst:innen gehört, dass sie „alles“ getestet haben wollen. 

Wie siehst du das? Wie findest du ein Mittelmass, oder willst du auch alles testen? ;-)

Christoph:

Natürlich wäre es schön, wenn man alles testen könnte. Aber die kombinatorischen Möglichkeiten gehen so schnell ins Endlose, dass es absolut unmöglich ist, alles zu testen. Ich glaube, das Wichtigste ist, zu verstehen, was realistische Szenarien sind. Es kommt darauf an, was passieren kann. Was sind die Risiken?

Für mich ist der wichtigste Anhaltspunkt, ob wir eine öffentliche Software testen oder eine Software, die für Expert:innen gedacht ist. 

Im aktuellen Projekt bauen wir Software für Fachanwender:innen. Da setzen wir voraus, dass sie nicht versuchen, das System kaputt zu machen. Hier können wir viele Edge-Cases, die wir bei einer öffentlichen Software testen müssten, weglassen. Das ist aber keine allgemeingültige Antwort. Der Punkt ist, wirklich zu verstehen, was das Umfeld ist, in dem wir uns bewegen und wo die Risiken in der Business Domain liegen.

Pia:

Ein sehr aktuelles Thema ist Barrierefreiheit (Accessibility). Hierzu kommen in nicht allzu ferner Zukunft gesetzliche Vorgaben. Hattest du schon Berührungspunkte mit diesen nicht-funktionalen Anforderungen?

Christoph:

Wir haben mal bei einer App versucht, nur mit dem Screenreader zu navigieren. Das war eine spannende Erfahrung. Wir sind aber nie so weit gekommen, dass wir auf Barrierefreiheit optimiert hätten. Letztlich weiss ich auch nicht, wie viel man als nicht-eingeschränkte Personen tatsächlich Barrierefreiheit testen kann. Wenn meine Software ein UI hat und ich möchte testen, ob sie für eine blinde Person bedienbar ist, kann ich zwar meine Augen schliessen, aber ich denke deshalb nicht wie jemand, der/die nicht sehen kann. Dasselbe gilt für Personen mit motorischen Einschränkungen. Ich kann Annahmen treffen, aber was es tatsächlich im Detail bedeutet...? Da liegt noch viel Arbeit vor uns.

Pia:

Sehe ich auch so. Ich denke, bei Barrierefreiheit ist es besonders wichtig, so früh wie möglich daran zu denken. Bereits im Requirements Engineering und vor allem in der Entwicklung. Es ist essentiell, Entwickler:innen zu sensibilisieren, wie eine Applikation barrierefrei gebaut werden kann. Wenn man eine App im Nachhinein accessible machen muss/möchte, ist das meist mit grossem Aufwand verbunden und sehr fehleranfällig.

Christoph:

Umso wichtiger ist: Keep it simple! Je komplizierter ein UI ist, desto schwieriger wird Barrierefreiheit. Das wichtigste Prinzip bei Accessibility ist daher: Alles was nicht nötig ist, weglassen. 

Pia:

Wir müssen die richtige Balance finden. Unsere Software soll barrierefrei sein, schön aussehen und für alle intuitiv benutzbar sein. Wir gehen durch eine spannende Zeit mit wichtigen Veränderungen.

Christoph, du warst und bist in verschiedenen Branchen unterwegs. Siehst du eine Branche, die offener für das Thema Qualität ist? 

Christoph:

Es kommt darauf an, was gute Qualität heisst ;-) Das hängt für mich immer vom Kontext ab. 

In der Finanzbranche ist der grösste Schaden entweder Reputationsverlust oder monetärer Schaden. Monetären Schaden kannst du mit mehr Geld beheben. In der Finanzbranche ist die Frage, wie viel Qualität es braucht, eine rein finanzielle. Es sind im Normalfall keine Menschenleben betroffen. Es gibt kein gesundheitliches Risiko. Daher ist man hier, nach meiner Erfahrung, eher dazu geneigt, ein gewisses Risiko einzugehen. 

Wenn es aber um Gesundheit und Menschenleben geht, hoffe ich doch, dass Qualität einen anderen Stellenwert hat. Da würde ich von Beginn an rigoros darauf achten, dass die Produkte sicher sind.

Im Moment bin ich irgendwo dazwischen, in einer Ingenieur-Abteilung bei einem Transportunternehmen. Da merkst du, Ingenieur:innen sind es gewohnt, sehr genau zu arbeiten. Sie kennen aber auch die realen Gegebenheiten auf einer Baustelle. Da wird vieles pragmatisch gelöst. Wir bewegen uns hier also irgendwo in der Mitte. Es ist nicht wie in der Finanzbranche, wo man vieles finanziell regeln kann. Es ist aber auch nicht so rigoros wie in einem regulierten Gesundheitsbereich. 

Pia:

Ich würde gerne nochmal auf agile Teams zu sprechen kommen. 

Abgesehen davon, dass es Sinn macht, eine Person für den kritischen Quality-Blick im Team zu haben, wie sollte deines Erachtens ein agiles Team zusammengesetzt sein? Wie sollten die Teammitglieder zusammenarbeiten? 

Ich habe leider oft gesehen, dass man eine Wasserfall-Organisation in ein agiles Team gequetscht hat und so die bestehenden Engpässe und den Stress nur um ein Vielfaches verschärft hat. 

Christoph:

Ich glaube, das Wichtigste ist, dass man sehr eng zusammenarbeiten kann und Vertrauen in einander hat. Sowohl als Business Analyst als auch in einer Testing-Rolle arbeite ich gerne mit der Entwicklung zusammen. Ich schaue mir gerne den Code an und was sich der/die Entwickler:in überlegt hat. 

Ich arbeite am liebsten und auch sehr erfolgreich mit kurzen Feedback-Loops. Idealerweise schaue ich fertige Teile mit den Entwickler:innen auf der Entwicklungsumgebung an. So können wir direkt Anpassungen vornehmen. Ausserdem sind wir beide zur gleichen Zeit im selben Kontext. Wenn etwas fertig ist, haben wir es bereits mit vier Augen angeschaut und müssen es nicht noch Wasserfall-like testen. 

Pia:

Ja, so arbeite ich auch am Liebsten. Zum Glück geht es in vielen Branchen und Projekten immer mehr in diese Richtung. 

Christoph:

Genau. In Anbetracht dieser Entwicklung ist es umso wichtiger, dass man alle Rollen im Team vertreten hat. Dass jemand mit Quality-Fokus ein vollwertiges Teammitglied ist. Auch Requirements Engineers sind Teil des Teams. Je nach Fähigkeiten kann der/die Product Owner:in das Requirements Engineering machen. Das bedingt aber, dass diese Person wirklich Zeit hat, nahe beim Team zu sein. Das kann eine Herausforderung sein. Vor allem, wenn viel Stakeholdermanagement nötig ist. 

Pia:

Ich sehe das wie du, Christoph. Ich denke, dass wir mit cross-funktionalen Teams sehr gut aufgestellt sind, um Qualität sicherzustellen und auch einfach lässig zusammenzuarbeiten.

In letzter Zeit höre ich immer wieder „ Wir testen erst in der Produktion“ oder „Wenn etwas nicht gut ist, melden sich die Benutzer:innen schon“. Ist dir das auch aufgefallen? Wie findest du das?

Christoph:

Hier stellt sich wieder die Frage: Was sind die Risiken? Was ist das Schlimmste, das passieren kann? Für mich ist Testing vor der Produktion ein wichtiges Sicherheitsnetz. Mit diesem Netz fängst du die grossen Fische. Du stellst sicher, dass es die schlimmsten Probleme nicht auf Produktion schaffen. Natürlich kann man mit Testing nicht alles abdecken. Vor allem sogenannte „unknown unknowns“. Testing ist ein wichtiges Mittel um zu prüfen, dass derartige Fehler nur ein Mal passieren. 

Der Schlüssel hier heisst Automatisierung. Eine Maschine soll vorab die wichtigsten Funktionen prüfen. Natürlich muss sich zuerst jemand überlegen, was die wichtigsten Funktionen bzw. die schlimmsten Probleme sind und wie wir sicherstellen können, dass diese nicht auftreten. Das erfordert viel Fachwissen, das bis auf Weiteres von echten Menschen eingebracht werden sollte.

Pia:

Hast du dich da schon mal von Chat GPT unterstützen lassen?

Christoph:

Habe ich ehrlich gesagt nicht. Ich bin da noch ein bisschen kritisch. Ich glaube, die Projekte, in denen ich unterwegs bin, sind sehr fachspezifisch. Ich weiss nicht, wie viele Trainingsdaten die AI hierzu schon enthält.

Wenn es darum geht, Kombinationen von Testdaten zu produzieren, kann ich mir vorstellen, dass AI eine gute Unterstützung sein kann. Ich glaube, es bleibt spannend.

Pia: 

Absolut. Ich sehe hier grosses Potenzial und habe zugleich keine Angst, dass wir weg automatisiert werden, auch nicht von der künstlichen Intelligenz.

Christoph:

AI bringt ausserdem ganz neue Herausforderungen. Wie stellen wir sicher, dass künstliche Intelligenzen auch wirklich die Anforderungen erfüllen? Ein bisschen mit Chat GPT spielen ist das eine, aber ganze Business Applikationen darauf zu basieren ist etwas völlig anderes. Und das zu testen, stelle ich mir als sehr spannende Herausforderung vor. 

Pia:

Genau. Wir bleiben auf jeden Fall dran. 

Aus deiner langjährigen Erfahrung, Christoph, was sind für dich die wichtigsten Erfolgsfaktoren für Built-in Quality bzw. für ein qualitativ hochwertiges Softwareprodukt?

Christoph:

Das Wichtigste ist, das Umfeld zu kennen. 

Es gibt nicht DAS Produkt, das in jedem Umfeld gut ist. Es kommt auf den Kontext an. Den Kontext kannst du nur verstehen, wenn du mit Benutzer:innen sprichst und Feedback mit Prototypen und ersten Lösungen einholst. Diese verbesserst du dann iterativ.

In diesem Sinn gibt es nicht DIE Qualität, sondern Qualität ist kontextabhängig.

Das ist für mich absolut entscheidend, um gute Produkte zu bauen. Und wie baust du die? 

Das geht nur in einem Team, in dem man sich gegenseitig vertraut, eng zusammenarbeitet und sich schnell Feedback geben kann. Man arbeitet nicht gegeneinander, sondern miteinander.

Pia: Du sagst es! Herzlichen Dank, Christoph.