Ein QA Engineer prüft nicht, ob die Software funktioniert, sondern ob sie das Richtige tut.

Wenn ein Vorhaben in Verzug ist, wird als Erstes beim Prüfen gekürzt. Das ist nachvollziehbar, weil Prüfen der Teil ist, der nichts Sichtbares baut. Gekürzt wird dabei aber selten nur das Testen. Gekürzt wird die Frage, ob das Gebaute überhaupt das Richtige tut und diese Frage stellt später jemand anders: die Mitarbeiterin, die den Ablauf zum ersten Mal im Betrieb durchspielt, oder der Kunde, der eine falsche Rechnung bekommt. Wir erklären, was die Rolle im Alltag tut, worin sie sich vom Testen unterscheidet und was ein Fehler kostet, je nachdem, auf welcher Stufe er auffällt.

Testen prüft, ob etwas funktioniert, Qualitätssicherung prüft, ob es das Richtige tut.

Der Unterschied lässt sich an einem einzelnen Eingabefeld zeigen. Ein Test prüft, ob das Feld für die Kundennummer Ziffern annimmt, Buchstaben ablehnt, die Eingabe speichert und beim nächsten Aufruf wieder anzeigt. Das ist notwendige Arbeit, sie ist eindeutig beschreibbar und deshalb kann eine Maschine sie übernehmen.

Ein QA Engineer fragt etwas anderes. Warum steht dieses Feld hier. Wer füllt es aus, mit welcher Unterlage vor sich und was macht diese Person, wenn sie die Nummer nicht kennt. Ist die Eingabe Pflicht, weil ein Prozess sie braucht, oder weil sie in einer Sitzung einmal gefordert wurde. Was passiert mit den zweitausend Datensätzen aus dem Altsystem, in denen dieses Feld leer ist.

Das sind keine Testfälle, das sind Fragen an die Anforderung. Software, die jeden Testfall besteht und die falsche Anforderung erfüllt, ist fehlerfrei und trotzdem unbrauchbar. Deshalb sitzt diese Rolle näher bei der Fachseite als bei der Entwicklung, auch wenn sie technisch arbeitet und technisch verstanden werden muss.

Die Arbeit beginnt bei der Anforderung und nicht beim fertigen Bildschirm.

Ein QA Engineer, der erst am Ende dazukommt, kann nur noch zählen, was schiefgelaufen ist. Der Nutzen entsteht früher und er entsteht mit einer unbequemen Sorte Fragen: Was soll passieren, wenn zwei Personen denselben Datensatz gleichzeitig ändern. Was gilt als abgeschlossen. Was macht das System, wenn die Schnittstelle zur Buchhaltung eine Stunde nicht antwortet.

Diese Fragen sind unangenehm, weil sie einen Entscheid verlangen, den niemand treffen will. Genau das ist ihr Wert. Jede dieser Fragen wird entweder vor dem Bauen beantwortet oder nach dem Produktivstart und dazwischen liegt der ganze Unterschied. Wer sie vorher stellt, bekommt eine Antwort in einer Sitzung. Wer sie nachher stellt, bekommt sie zusammen mit korrigierten Daten und einer Erklärung an den Kunden.

Dazu gehört auch die Prüfung, ob die Anforderung überhaupt zur Arbeit passt, die tatsächlich gemacht wird. Das ist der Punkt, an dem sich die Rolle mit der Person überschneidet, die mit den Leuten redet, bevor irgendetwas gezeichnet wird. Der Unterschied ist die Richtung: Die eine Rolle sucht heraus, wie gearbeitet wird, die andere prüft, ob das Gebaute dieser Arbeit standhält, auch am Monatsende und auch mit unvollständigen Daten.

Ein Fehler wechselt auf jeder Stufe die Währung, in der man ihn bezahlt.

Die Zahlen dazu sind in jedem Unternehmen andere, aber das Muster ist immer dasselbe und man kann es an einer einzigen falschen Berechnung durchspielen. Fällt sie der Entwicklerin auf, während sie den Code schreibt, kostet die Korrektur Minuten, weil alles im Kopf präsent ist. Fällt sie zwei Wochen später beim Prüfen auf, kostet sie ein bis zwei Stunden: sich wieder einlesen, korrigieren, erneut ausliefern, nachprüfen.

Nach dem Produktivstart ändert sich die Rechnung grundsätzlich, weil nicht mehr nur Entwicklungszeit anfällt. Zur Korrektur kommen die Suche nach den betroffenen Datensätzen, ihre Bereinigung, eine Mitteilung an alle, die eine falsche Zahl gesehen haben und der Aufwand im Support. Aus zwanzig Minuten Arbeit werden ein Tag und drei beteiligte Personen und einer davon ist meistens jemand aus der Geschäftsleitung.

Bei einer Anwendung, die zwischen CHF 10'000 und CHF 30'000 gekostet hat, ist ein solcher Tag verkraftbar. Fünf davon im ersten halben Jahr sind es nicht mehr und sie kommen selten einzeln, weil dieselbe unklare Anforderung meistens an mehreren Stellen falsch umgesetzt wurde. Der Aufwand, der das verhindert, ist im Vergleich klein: ein bis zwei Tage, in denen jemand die Anforderungen durchgeht und die offenen Fälle benennt, bevor gebaut wird.

Diese Rechnung ist seit KI wichtiger geworden, nicht unwichtiger. Der Teil, den man tippt, ist um ein Vielfaches schneller geworden, geprüft wird gleich langsam wie vorher. Wenn in derselben Woche das Dreifache entsteht, entsteht auch das Dreifache an ungeprüften Annahmen.

Automatisiert wird, was sich oft genug wiederholt, alles andere wird von Hand geprüft.

Testautomatisierung wird gern als Ja oder Nein diskutiert und ist eine Rechnung. Ein automatisierter Durchlauf der wichtigsten zwanzig Abläufe kostet in der Einrichtung einige Tage und läuft danach bei jeder Änderung in wenigen Minuten. Das lohnt sich für alles, was bei jeder Auslieferung wieder stimmen muss: Anmeldung, Bestellung, Rechnung, Zahlung, Export in die Buchhaltung.

Es lohnt sich nicht für Abläufe, die sich noch jeden Monat ändern. Automatisierte Prüfungen müssen gepflegt werden und eine Sammlung, die nach jeder Änderung rot leuchtet, ohne dass jemand nachschaut, ist schlechter als keine: Sie kostet Zeit und liefert keine Aussage mehr. Ein QA Engineer entscheidet deshalb vor allem, was nicht automatisiert wird.

Ob eine Anwendung überhaupt prüfbar ist, wird lange vorher entschieden. Wo Software so gebaut ist, dass sich kein Zustand herstellen und keine Schnittstelle ersetzen lässt, bleibt jede Prüfung Handarbeit. Das gehört zu den Dingen, die man später nicht mehr billig ändern kann und es ist einer der Gründe, weshalb die beiden Rollen früh am selben Tisch sitzen sollten.

Für ein KMU ist das ein Auftrag von wenigen Tagen und keine Stelle.

Nicht jedes Unternehmen braucht die Rolle. Wer Standardsoftware einsetzt und sie so nutzt, wie sie geliefert wird, braucht sie nicht und niemand sollte ihm etwas anderes erzählen. Gebraucht wird sie, sobald etwas gebaut oder angepasst wird und Geld, Personendaten oder eine gesetzliche Pflicht daran hängen.

Drei Anzeichen sprechen dafür, dass sie fehlt. Nach jeder Auslieferung meldet der Betrieb Dinge, die vorher funktioniert haben. Niemand kann sagen, was getestet wurde, bevor etwas live ging. Oder das Prüfen macht dieselbe Person, die gebaut hat, weil sonst niemand da ist: Sie prüft dann verlässlich das, woran sie beim Bauen gedacht hat und genau das ist der blinde Fleck.

Der Aufwand ist überschaubar. Für ein Vorhaben in dieser Grössenordnung sind es wenige Tage am Anfang für die Anforderungen und danach ein halber bis ein Tag pro Auslieferung. Eine eigene Stelle wird daraus erst, wenn laufend entwickelt wird und mehrere Systeme gleichzeitig in Betrieb sind.

Bei uay gehört QA Engineer zur Disziplin Betrieb, Qualität und Sicherheit, neben System Engineer, Cyber Security Engineer und Data Engineer. Bei jedem Problem schauen wir zuerst, welche Rollen es braucht. Bei allem, was gebaut oder angepasst wird, ist diese dabei und sie kommt vor der ersten Zeile Code. Sie muss nicht bei uns liegen: Wenn der bestehende Partner die offenen Fälle benennt, bevor er baut, ist das der einfachere Weg. Wenn niemand zuständig ist, übernehmen wir es und bleiben gegenüber dem Kunden verantwortlich.