Deutsch 
Magyar 
English (UK) Der Artikel erschien ursprünglich im Magazin BA Karakter #10 .
Prolog
Als Vertreter der Software-Qualitätssicherung - oder einfacher gesagt: des Testens - fühle ich mich hier in der V. BA-Bridge-Blogartikelreihe ein wenig wie ein Fremdkörper. Gleichzeitig war mein grundlegendes Bauchgefühl immer, dass Business-Analysten und Softwaretester im Kern verwandte Seelen sind - oder zumindest nahe Verwandte, wenn nicht sogar ganz sicher Nachbarn.
Ich begann 2012 bei Fundamenta-Lakáskassza als IT-Projektmanager zu arbeiten. Damals gab es kein eigenständiges Testteam, sondern ausschließlich ein Business-Analysis-Team. Es war selbstverständlich, dass der Großteil der Testaktivitäten von den Business-Analysten durchgeführt wurde. Die Tests eines Programms zur koordinierten Einführung mehrerer IT-Systeme - einschließlich des Austauschs des zentralen Kontoführungssystems - wurden von Business-Analysten und Fachbereichsanwendern durchgeführt, unter der Leitung professioneller externer Testmanager. Ein Ergebnis dieses IT-Programms war der Aufbau einer eigenständigen Testorganisation.
Heute, als projektverantwortliche Führungskraft in einem Unternehmen, das Testdienstleistungen erbringt, erlebe ich, dass jedes Großunternehmen über eine für das Testen verantwortliche Organisation verfügt und selbst bei KMU häufig ein oder zwei Tester bzw. zumindest eine für das Testen verantwortliche Person vorhanden sind. Auf Business-Analysis-Teams habe ich weniger Einblick; daher mag dies auch eine durch meine eigene Verfügbarkeitsheuristik verzerrte Wahrnehmung sein. Dennoch habe ich den Eindruck, dass viele Großunternehmen mehr Tester als Business-Analysten beschäftigen. Ich verfüge nicht über belastbare Daten oder Statistiken, die dies eindeutig belegen würden. Aber als Gedankenexperiment nehmen wir einmal an, dass Unternehmen tatsächlich mehr Softwaretester als Business-Analysten beschäftigen. Im Übrigen bestätigt auch Google Gemini diese Annahme.
Für den offensichtlichen Überhang an Softwaretestern gibt es natürlich mehrere Ursachen und Erklärungen. Dennoch lohnt sich der Gedanke, ob nicht vielleicht deshalb mehr Tester benötigt werden, weil es zu wenige Business-Analysten gibt.
Der Tester als Tierarzt
Es gibt diesen alten Witz von einem Tierarzt, der krank wird und zum Hausarzt geht. Der Hausarzt bittet ihn herein und sagt: „Kommen Sie, setzen Sie sich und erzählen Sie mir, welche Beschwerden Sie haben.“ Darauf der Tierarzt: „Na ja, so ist es natürlich einfach.“
Wann hat es ein Tester also leicht? Dann, wenn eine gute Spezifikation vorliegt. Eine Spezifikation, die bereits auf der Grundlage notwendiger Abstimmungen, Analysen und Entscheidungen erstellt wurde. Eine Spezifikation mit verständlichen Anforderungen, in der Prozessverzweigungen vollständig durchdacht und sauber aufgelöst sind. Eine Spezifikation, die den fachlichen Bedarf und die Perspektive der Endanwender bereits berücksichtigt und idealerweise auch zugehörige Screen-Designs und Wireframes enthält. In solchen Fällen lassen sich Testfälle schnell und effizient erstellen, und erfahrungsgemäß treten auch während der Testdurchführung weniger Fehler auf - wobei natürlich weiterhin viel von der Umsetzung und dem Entwickler abhängt.
In der Praxis begegnen unsere Testkollegen jedoch meist Fällen, in denen dem Softwareprodukt "das Fell ausfällt", "es seltsame Pieptöne von sich gibt" oder "es seit Tagen keinen Stuhlgang hatte". Dann beginnt das Rätselraten: Warum funktioniert diese Software nicht richtig? Was genau ist ihr Problem? Und was verhindert den ordnungsgemäßen Betrieb - sofern wir überhaupt wissen, wie das Sollverhalten aussieht?
Zum Glück ähneln wir in einer Hinsicht doch eher dem Hausarzt als dem Tierarzt: Wir arbeiten mit Menschen. Also beginnt das Nachfragen, gefolgt von Abstimmungen mit Vertretern des Fachbereichs, im Idealfall mit einem Business-Analysten - sofern es im Projekt einen gibt -, sowie mit dem Entwickler und dem Systemanalytiker. Nach diesen Abstimmungen setzt sich das Gesamtbild allmählich zusammen - ebenso wie die Testfälle und das erwartete Verhalten der Software.
Das aus dem Gleichgewicht geratene BA-QA-Verhältnis
Bei TestIT suchen wir gezielt nach testbezogenen Aufgaben und Use Cases, bei denen sich KI sinnvoll einsetzen lässt. Als Ausgangspunkt baten wir 10 bis 15 unserer Testexperten, die auf unterschiedlichen Projekten arbeiten, um eine Einschätzung dazu, wie sich ihre Arbeitszeit auf verschiedene Testaktivitäten verteilt. Für den Bereich der Testfallerstellung - also das Lesen der Spezifikation, die Abstimmung der Anforderungen, das Schreiben der Testfälle sowie deren Review und Validierung - zeigte sich, dass dieser Anteil je nach Senioritätsstufe variiert, insgesamt jedoch einen erheblichen Teil der Tätigkeit eines Testers ausmacht.
Anteil der Testfallerstellung an den Aufgaben eines Testers | |
Senior Tester | 30-40% |
Mid-Level-Tester | 40-50% |
Junior Tester | 60-70% |
Die oben genannten Erkenntnisse haben uns darin bestärkt, uns mit einem inzwischen nahezu trivialen KI-Anwendungsfall zu befassen: der Generierung von Testfällen aus Spezifikationen. Die Testfallerstellung ist für Tester eine wesentliche Tätigkeit, und zugleich ist sie für Sprachmodelle grundsätzlich gut verständlich: Ein Text muss interpretiert werden, aus dem anhand bestimmter Kriterien wiederum Text - nämlich ein Testfall - generiert werden soll. Eines der größten Hindernisse dabei ist jedoch, dass entweder keine Spezifikation vorhanden ist oder ihre Qualität unzureichend ist. Sie ist nicht ausreichend strukturiert, enthält nicht alle erforderlichen Informationen oder weist Widersprüche auf. In agilen Projekten kann die Spezifikation dabei durch eine User Story und Akzeptanzkriterien ersetzt werden.
Im Rahmen eines PoC, bei dem uns eine hochwertige Spezifikation zur Verfügung stand, aus der zuvor bereits auf herkömmliche Weise Testfälle erstellt worden waren, kamen wir zu dem Ergebnis, dass sich der Aufwand für die Testfallerstellung mit Hilfe eines speziell dafür vorbereiteten LLM um rund 60 % reduzieren lässt. Dies ist zunächst ein erstes Ergebnis; künftig werden wir weitere Messungen durchführen. Wir gehen jedoch davon aus, dass sich der Aufwand für die Testfallerstellung insgesamt um 30-50 % senken lässt. Diese Größenordnung ist jedoch bereits ein klarer Indikator dafür, dass sich mit guter Vorbereitung - und gegebenenfalls mit höherem Business-Analysis-Aufwand - der Aufwand für Testaktivitäten reduzieren lässt. Aus einer anderen Perspektive betrachtet kann dadurch auch die Softwarequalität gesteigert werden, dass der Testzyklus verkürzt wird und innerhalb eines gegebenen Zeitrahmens mehr Iterationen möglich werden.
Ich habe keinen belastbaren Richtwert dafür, wie viele QA-Ressourcen auf einen BA entfallen sollten. Das obige Beispiel zeigt jedoch, dass eine Erhöhung des BA-Anteils Auswirkungen auf die QA-Aufgaben hat und ein gut austariertes Verhältnis im Einzelfall sogar den Gesamtaufwand über den gesamten Softwareentwicklungslebenszyklus hinweg reduzieren kann.
Ideen für Business Analysts aus der Perspektive eines Testers
Mir sind zwei Ideen eingefallen, die die Zusammenarbeit auch aus praktischer Sicht unterstützen können und sich sogar kurzfristig sowie ohne größeren Zusatzaufwand einführen lassen.
Die erste ist das statische Testen, also das Prüfen von Anforderungen bzw. das Überprüfen der fertiggestellten Spezifikation aus Testsicht, noch bevor mit der Codierung begonnen oder die Anwendung ausgeführt wird. Ziel ist es, festgestellte Lücken und Fehler bereits in dieser frühen Phase zu identifizieren und zu beheben. In der Praxis sehe ich das nur sehr selten. Unsere Kunden binden uns typischerweise erst dann in das Testen ein, wenn die Software bereits auf den Weg gebracht wurde. Dabei handelt es sich um eine sehr einfache und kostengünstige Form des Shift-Left-Ansatzes, also der Vorverlagerung von Test- und Qualitätssicherungsaktivitäten auf einen möglichst frühen Zeitpunkt im Softwareentwicklungszyklus. Liebe Business-Analyst-Kollegen: Wenn ihr eure Testkollegen bislang noch nicht mit statischem Testen eingebunden habt, dann ist jetzt der richtige Zeitpunkt, damit zu beginnen.
Mein zweiter Gedanke ist, dass sich Quality Gates bereits in der Phase der Entstehung des Business-Bedarfs und der Spezifikation einführen ließen. Möglicherweise gibt es hierfür bereits gute Praktiken, aber in vielen Projekten, an denen wir beteiligt sind, ist meine Erfahrung, dass das Konzept des Quality Gates erst mit dem Release beginnt - also ab dem Zeitpunkt, zu dem bereits Code vorhanden ist: Entwicklertests, funktionale Tests, Integrationstests und UAT. Es wäre sinnvoll, bereits für den fachlichen Bedarf selbst ein Quality Gate zu definieren. Zum Beispiel: Beruht der Business-Bedarf auf einer fundierten Analyse? Ist er verständlich formuliert? Ist die Ziel- bzw. Endanwendergruppe identifiziert? Im Fall bestehender Software: Zu welchem Prozentsatz wird die zu ändernde Funktion tatsächlich genutzt? Und im Fall einer Spezifikation: Wurde sie von den erforderlichen Fachbereichen freigegeben? Wurde für das Dokument bzw. die User Story ein statischer Test durchgeführt?
Epilog
Vor diesem Hintergrund bin ich der Ansicht, dass die Grundlage guter Softwarequalität in einer guten Business-Analyse und in klar formulierten Anforderungen liegt. Darauf aufbauend lässt sich das Softwaretesten deutlich beschleunigen, und der Fokus verlagert sich weg vom Verständnis der Anforderungen und des erwarteten Verhaltens hin zur Überprüfung der Umsetzungsqualität.
Eine gute BA-QA-Zusammenarbeit ist notwendig, wenn wir die Time-to-Market verkürzen und mit den immer kürzer werdenden Release-Zyklen Schritt halten wollen.
Ich bin überzeugt, dass wir unser gemeinsames Ziel - qualitativ hochwertige Software und Business-Anwendungen bereitzustellen, die die Anforderungen der Endanwender erfüllen und sich zugleich schnell und effizient an sich kontinuierlich verändernde Bedürfnisse anpassen lassen - nur durch gemeinsame Anstrengungen erreichen können.
Ich bin zuversichtlich, dass sich zwischen uns künftig spannende Formen der Zusammenarbeit entwickeln können. Selbst wenn wir zunächst nur gemeinsam der Annahme nachgehen könnten, ob Unternehmen tatsächlich mehr Tester als Business Analysts beschäftigen - und welches Verhältnis dabei angemessen wäre -, wäre bereits das ein äußerst spannendes Thema.
Autor: Gergely Gayerhosz, Delivery Manger von TestIT
