Shift-Left ist nicht neu – die QA schliesst den Kreis
Dieser Beitrag zeigt, warum moderne "Shift-Left"-Praktiken gar nicht neu sind: Sie sind eine Rückkehr zum strukturierten, disziplinierten Engineering, das QA-Teams früher geleistet haben. Er erklärt, wie aus geschäftlichen Bedürfnissen Anforderungen und Spezifikationen werden, warum gute Fragen wichtiger sind als schicke Tools und warum viele agile Teams nicht wegen der Methode Mühe haben, sondern wegen der Art, wie sie umgesetzt wird.
Testen war einmal ernsthaftes Engineering. Dann galt es als teuer, langsam und überflüssig. QA-Abteilungen wurden aufgelöst.
Dann kam die sogenannte Shift-Left-Bewegung – ein neuer Name für Praktiken, die viele QA-Teams schon seit Jahren anwendeten.
Wenn du aber wie ich schon lange dabei bist, erkennst du in diesen Aktivitäten auf der linken Seite genau das, was QA-Teams früher gemacht haben, nur mit weniger Zeremoniell und mehr kritischem Denken. Die Branche hat die Angewohnheit, alte Lektionen unter neuen Etiketten wiederzuentdecken, und dieselben Herausforderungen tauchen gern in anderer Form wieder auf.
Im Softwaretesting hält sich ein hartnäckiges Missverständnis: Um ernsthafte Probleme aufzudecken, brauche es schicke neue Tools, KI-Plattformen oder schwergewichtige Automation-Frameworks. Das stimmt nicht. Manchmal reichen ein Bleistift, Erfahrung und die Fähigkeit, die richtigen Fragen zu stellen.
Nimm diese klassische agile User Story:
Als Nutzer möchte ich mich mit meinem Benutzernamen und meinem Passwort anmelden, um auf das System zuzugreifen.
Das beschreibt eine Absicht, ist aber keine Anforderung.
Bevor du widersprichst, frag dich:
- Was gilt als Anforderung und was als Spezifikation?
- Was muss verifiziert und was sollte validiert werden?
Die ganze Geschichte beginnt hier: Die geschäftliche Absicht wird mit einem klaren, strukturierten Systemverhalten verknüpft.
(Das ist eine vereinfachte Version dessen, was zu tun ist, damit die Lesezeit kürzer bleibt.)
Geschäftsbedarf (BN)
Er drückt eine Absicht aus, keine Umsetzung.
| ID | Aussage |
|---|---|
| BN01 | Der Zugriff auf die Software muss kontrolliert werden. |
| BN02 | Wir rechnen für das Jahr 2026 mit 1200 Nutzern, einer täglichen Nutzungsrate von 5 Prozent und einem jährlichen Wachstum von 12,5 Prozent. |
Anforderung (REQ)
Legt fest, was das System tun muss – nicht wie.
| ID | Aussage |
|---|---|
| REQ01 | Das System muss Nutzer authentifizieren, bevor es Zugriff gewährt. |
Spezifikation (AUTH, PERF)
Beschreibt, wie die Anforderung erfüllt wird.
| ID | Aussage |
|---|---|
| AUTH01 | Die Authentifizierung muss über OAuth 2.0 erfolgen. |
| AUTH02 | Das System muss eine Login-Maske mit Eingabefeldern für Benutzername und Passwort anzeigen. |
| AUTH03 | Das System muss Zwei-Faktor-Authentifizierung (2FA) per SMS oder TOTP unterstützen. |
Die richtigen Fragen stellen
Um die Anforderung und ihre Spezifikationen zu validieren, verwenden wir einen Fragebogen auf Basis einer verbindlichen Vorlage. Die QA erstellt den Fragebogen, damit er zur geschäftlichen Vision von Qualität passt. Die Antworten müssen dokumentiert werden und dürfen auch "Nicht zutreffend", "als akzeptabel geringes Risiko eingestuft", TBD usw. lauten. Der Fragebogen deckt mehrere Themen ab:
- Sicherheit und Komplexität
- Barrierefreiheit
- Was-wäre-wenn-Szenarien
- Verhalten von Modals
- Fehlerbehandlung und Feedback
- Performance und Last
- Recht und Compliance
Einige Beispielfragen:
| # | Frage |
|---|---|
| Q01 | Welche Passwortregeln müssen durchgesetzt werden? |
| Q02 | Soll 2FA obligatorisch oder optional sein? |
| Q03 | Was muss passieren, wenn SMS oder TOTP fehlschlägt? |
| Q04 | Soll die Login-Maske Screenreader unterstützen? |
| Q05 | Welche Standards für Barrierefreiheit müssen erfüllt werden? |
| Q06 | Was passiert nach drei fehlgeschlagenen Anmeldeversuchen? |
| Q07 | Was passiert, wenn der OAuth-Provider nicht erreichbar ist? |
| Q08 | Sollen Nutzer über verdächtige Aktivitäten informiert werden? |
| Q09 | Soll das Modal den Fokus festhalten und sich schliessen lassen? |
| Q10 | Muss es auf allen Geräten responsive sein? |
| Q11 | Welche Fehlermeldungen sollen angezeigt werden? |
| Q12 | Müssen Fehlermeldungen verhindern, dass gültige Benutzernamen preisgegeben werden? |
| Q13 | Welche Antwortzeit wird unter Spitzenlast erwartet? |
| Q14 | Muss Rate Limiting implementiert werden? |
| Q15 | Soll die Einwilligung der Nutzer vor der Authentifizierung ausdrücklich eingeholt werden? |
| Q16 | Müssen die Authentifizierungs-Logs die DSGVO oder andere Gesetze einhalten? |
Diese Fragen lösen sinnvolle Diskussionen zwischen QA, Entwicklern und Business-Stakeholdern aus – bevor auch nur ein Testfall ausgeführt oder eine Zeile Code geschrieben wird.
Erweiterte Spezifikationen (nachverfolgbar & testbar)
Richtig gemacht, ist jede Anforderung mit detaillierten, testbaren Spezifikationen verknüpft.
Hier ein Ausschnitt als Beispiel:
Authentifizierungsprotokoll
- AUTH01 - Das System muss OAuth2.0 als Authentifizierungsprotokoll verwenden
Login-Oberfläche
- AUTH02 - Das System muss eine Login-Maske anzeigen, um die Authentifizierung zu starten
- AUTH03 - Die Login-Maske muss Eingabefelder für Benutzername und Passwort enthalten
Umgang mit Zugangsdaten
- AUTH04 - Das System muss den eingegebenen Benutzernamen und das Passwort beim Identity Provider prüfen
- AUTH05 - Das System muss den Zugriff verweigern, wenn die Zugangsdaten ungültig sind
Zwei-Faktor-Authentifizierung (2FA)
- AUTH06 - Das System muss Zwei-Faktor-Authentifizierung unterstützen
- AUTH07 - 2FA muss per SMS oder TOTP verfügbar sein
- AUTH08 - Das System muss es Nutzern ermöglichen, ihre bevorzugte 2FA-Methode zu wählen
- AUTH09 - Das System muss 2FA vor dem Gewähren des Zugriffs erzwingen, wenn sie aktiviert ist
Fehlerbehandlung
- AUTH10 - Das System muss Nutzer über fehlgeschlagene Authentifizierungsversuche informieren
- AUTH11 - Das System muss einen Fallback-Mechanismus bereitstellen, wenn die Zustellung per SMS oder TOTP fehlschlägt
Performance und Last
- PERF01 - Das System muss bis Ende 2026 die Authentifizierung für bis zu 1200 registrierte Nutzer unterstützen
- PERF02 - Das System muss eine tägliche aktive Nutzungsrate von 5 Prozent bewältigen, was unter normalen Bedingungen 60 gleichzeitigen Nutzern entspricht
- PERF03 - Das System muss so skalierbar sein, dass es ein jährliches Wachstum von 12,5 Prozent trägt, also rund 1350 Nutzer bis Ende 2027 und 1520 bis Ende 2028
- PERF04 - Die Antwortzeit der Authentifizierung darf unter erwarteter Last bei 95 Prozent der Anmeldeversuche 2 Sekunden nicht überschreiten
- PERF05 - Das System muss für die Authentifizierung eine Verfügbarkeit von 99,9 Prozent Uptime gewährleisten, geplante Wartungen ausgenommen
- PERF06 - Das System muss Rate Limiting implementieren, um Missbrauch zu verhindern und bei Spitzenauslastung eine faire Verteilung der Ressourcen sicherzustellen
- PERF07 - Das System muss unter simulierter Spitzenlast getestet werden, um Performance-Schwellenwerte zu validieren und Engpässe zu erkennen
Nachverfolgbarkeit: die vergessene Kunst
Eine Traceability-Matrix verknüpft Geschäftsbedarf, Anforderungen und Spezifikationen miteinander und macht so klar, warum es jedes Feature gibt und wie es getestet wird. Das war früher das Rückgrat von ernsthaftem Engineering in der QA, und die heutige "Shift-Left"-Bewegung kehrt lediglich zu diesen grundlegenden Prinzipien zurück.
So sah ernsthaftes Engineering in der QA aus.
| ID | Typ | Aussage | Verknüpft mit |
|---|---|---|---|
| BN01 | Geschäftsbedarf | Der Zugriff auf die Software muss kontrolliert werden. | REQ01 |
| BN02 | Geschäftsbedarf | 1200 Nutzer bis 2026, 5 Prozent tägliche Nutzung, 12,5 Prozent jährliches Wachstum. | PERF01–PERF03 |
| REQ01 | Anforderung | Das System muss Nutzer authentifizieren, bevor es Zugriff gewährt. | AUTH01-AUTH11, PERF01-PERF07 |
| AUTH01 | Spezifikation | Die Authentifizierung muss über OAuth2.0 erfolgen. | REQ01 |
| AUTH02 | Spezifikation | Das System muss eine Login-Maske anzeigen, um die Authentifizierung zu starten. | REQ01 |
| AUTH03 | Spezifikation | Die Login-Maske muss Eingabefelder für Benutzername und Passwort enthalten. | REQ01 |
| AUTH04 | Spezifikation | Das System muss den eingegebenen Benutzernamen und das Passwort prüfen. | REQ01 |
| AUTH05 | Spezifikation | Das System muss den Zugriff verweigern, wenn die Zugangsdaten ungültig sind. | REQ01 |
| AUTH06 | Spezifikation | Das System muss Zwei-Faktor-Authentifizierung unterstützen | REQ01 |
| AUTH07 | Spezifikation | 2FA muss per SMS oder TOTP verfügbar sein. | REQ01 |
| AUTH08 | Spezifikation | Das System muss es Nutzern ermöglichen, ihre bevorzugte 2FA-Methode zu wählen. | REQ01 |
| AUTH09 | Spezifikation | Das System muss 2FA vor dem Gewähren des Zugriffs erzwingen, wenn sie aktiviert ist. | REQ01 |
| AUTH10 | Spezifikation | Das System muss Nutzer über fehlgeschlagene Authentifizierungsversuche informieren. | REQ01 |
| AUTH11 | Spezifikation | Das System muss einen Fallback-Mechanismus bereitstellen, wenn SMS oder TOTP fehlschlägt. | REQ01 |
| PerF01 | Spezifikation | Bis Ende 2026 bis zu 1200 registrierte Nutzer unterstützen. | REQ01 |
| PerF02 | Spezifikation | 5 Prozent tägliche aktive Nutzung bewältigen (60 gleichzeitige Nutzer). | REQ01 |
| PerF03 | Spezifikation | Für 12,5 Prozent jährliches Wachstum skalieren (1350 im Jahr 2027, 1520 im Jahr 2028). | REQ01 |
| PerF04 | Spezifikation | Antwortzeit der Authentifizierung bei 95 Prozent nicht über 2 Sekunden | REQ01 |
| PerF05 | Spezifikation | 99,9 % Uptime gewährleisten. | REQ01 |
| PerF06 | Spezifikation | Rate Limiting bei Spitzenauslastung implementieren. | REQ01 |
| PerF07 | Spezifikation | Spitzenlast zur Validierung simulieren. | REQ01 |
TL;DR – die QA schliesst den Kreis
- Testen war früher strukturiert, nachverfolgbar und kritisch.
- Moderne Praktiken wie "Shift-Left" entdecken wieder, was die QA längst wusste.
- Du brauchst keine komplexen Frameworks – du brauchst Disziplin, Klarheit und gute Fragen.
- Echte Qualität entsteht aus dem Verständnis für das Geschäft, nicht allein aus automatisierten Tests.
Ein letzter Gedanke
Neue Methoden der Softwareentwicklung wie Agile, RAD, XP, FDD (...) haben viele wertvolle Ideen in die Softwareentwicklung gebracht, etwa schnelleres Feedback, engere Zusammenarbeit und den Fokus darauf, kontinuierlich Mehrwert zu liefern. Doch Herausforderungen entstehen oft nicht nur bei der Einführung der Methode selbst, sondern auch in der Art, wie sie üblicherweise umgesetzt wird. In der Praxis werden wesentliche Klärungen, Anforderungen und Qualitätsüberlegungen häufig übersehen, unabhängig von der Methodik.
Bei House of Test helfen wir dir mit unserem methodischen und disziplinierten Vorgehen, deine Qualität im Griff zu behalten.
Ich helfe Teams zu verstehen, wie sich ihre Systeme verhalten, wenn die Realität unübersichtlich wird. Ich erkenne Muster, die andere übersehen, und erkläre sie in einfacher Sprache. Ausserhalb der Arbeit bastle ich an kleiner Elektronik und repariere Geräte – vor allem, weil ich genau wissen will, wie und warum Dinge kaputtgehen.
