Qualitätssicherung im Entwicklungsteam: Rollen, Teststrategie und Zusammenarbeit

Qualitätssicherung gehört in den Arbeitsfluss

Ein Qualitätsteam, das erst am Ende ein fertiges Produkt erhält, entdeckt Probleme spät und kennt oft die Entstehungsgründe nicht. Binden Sie Prüfungen deshalb an Anforderungen, Entwurf, Codeänderung und Freigabe. Der ISTQB-Lehrplan beschreibt die Zusammenarbeit zwischen Testenden, Entwicklern und Fachabteilungen bei Teststrategie und Abnahmetests. Er empfiehlt je nach Projekt mehrere Grade der Unabhängigkeit, etwa Komponentenprüfungen durch Entwickler, Systemprüfungen durch ein Testteam und fachliche Abnahme durch die zuständige Fachabteilung. Das sind mögliche Ebenen, keine Pflichtbesetzung für jedes Vorhaben.

Die zentrale Entscheidung lautet: Welche Fehler hätten für Nutzende, Umsatz, Betrieb oder Vertrauen die größten Folgen? Daraus folgt, was zuerst manuell geprüft, automatisiert wiederholt oder unabhängig bewertet werden sollte. Automatisierung ersetzt kein gutes Testdesign. Sie lohnt sich vor allem bei stabilen Abläufen, die regelmäßig und verlässlich wiederholt werden müssen.

Fiktives Beispiel: Preisberechnung im Bestellprozess

Fiktives, vereinfachtes Beispiel, keine Division5-Kundenreferenz: Ein Händlerportal berechnet Rabatte, Versandkosten und Steuer. Ein Fehler kann falsche Beträge anzeigen oder Bestellungen blockieren. Das Team plant daher nicht „alle Seiten einmal anklicken“, sondern prüft gezielt die Regeln: Rabattgrenzen, Kombinationen, Rundung, fehlende Adresse, Abbruch und erneuter Versuch.

Entwicklung ergänzt automatisierte Tests für die wiederkehrende Preislogik und Schnittstellen. Eine QA-Fachkraft entwirft Szenarien für Grenzfälle und prüft den Ablauf im Browser. Die Product Ownerin bestätigt fachliche Regeln und entscheidet, ob das Verhalten den Bedarf erfüllt. Vor der Veröffentlichung prüft die Fachseite zusätzlich einen realistischen Bestellfall. Diese Aufteilung verbindet schnelle Wiederholbarkeit mit menschlicher Bewertung.

Preisregel als Grenzfalltabelle festhalten

Die folgende Tabelle nutzt frei erfundene Werte nur zur Erklärung der Prüfmethode. Ersetzen Sie sie durch die freigegebene Geschäftsregel. QA sollte keine fehlende Preis- oder Rabattregel selbst erfinden.

Ergänzen Sie Versandkosten, Steuer, Gutscheine und Rückerstattung getrennt. Rundung kann je nach bestätigter Regel pro Position oder auf den Gesamtbetrag erfolgen. Lassen Sie die zuständige Fachperson festlegen, welche Variante gilt.

Verantwortung für Qualität im Team verteilen

Eine Teststrategie aus Risiko und Änderungsumfang ableiten

1. Risiko benennen: Was kann fehlschlagen, wen trifft es und wie schwer lässt es sich beheben?
2. Prüfpunkt wählen: Ist der Fehler am besten in einer Codekomponente, zwischen Systemen, im Browser oder fachlich im Gesamtprozess zu erkennen?
3. Prüfmittel wählen: Automatisieren Sie wiederkehrende, stabile Fälle. Nutzen Sie manuelle und explorative Prüfung für neue Abläufe, unklare Anforderungen und unerwartete Zustände.
4. Freigabe klären: Legen Sie fest, welche Befunde blockieren, wer Abweichungen bewertet und wer die Veröffentlichung freigibt.
5. Nach Änderungen nachziehen: Aktualisieren Sie Tests, wenn Regeln, Daten oder Schnittstellen sich ändern. Sonst schützt die Suite den alten Stand.

Arbeitsblatt für die nächste Produktänderung

• Änderung: Welcher konkrete Ablauf oder welche Regel ändert sich?
• Schadensfall: Was passiert bei falschem Ergebnis, Ausfall, Datenverlust oder unberechtigtem Zugriff?
• Grenzfälle: Welche leeren, doppelten, verspäteten oder widersprüchlichen Eingaben sind möglich?
• Prüfebene: Welcher Teil gehört in automatisierte Komponenten- oder Integrationstests? Was muss im echten Ablauf manuell geprüft werden?
• Verantwortliche: Wer erstellt die Prüfung, wer wertet Befunde aus und wer gibt fachlich frei?
• Freigaberegel: Welche offenen Fehler verhindern den Start und wer darf eine Ausnahme entscheiden?

Vor der Veröffentlichung: Blocker oder dokumentierter Restpunkt?

QA liefert nachvollziehbare Befunde. Die Produkt- oder Releaseverantwortung entscheidet anhand der vereinbarten Regel über die Veröffentlichung. Eine Testfachkraft sollte nicht allein für Geschäftsrisiken haftbar gemacht werden, die das Unternehmen nicht eingeordnet hat.

Wann eine zusätzliche QA-Rolle wenig bewirkt

Wenn Anforderungen erst nach der Entwicklung erklärt werden, fehlt der QA-Fachkraft der Entscheidungskontext. Wenn Entwickler keine Zeit für Code- und Komponententests erhalten, sammelt sich die Verantwortung am Ende des Prozesses. Wenn niemand Fehler priorisiert oder eine Freigabe verantwortet, bleibt ein Testbericht ohne Wirkung. Beheben Sie diese Teamregeln zusammen mit der Besetzung.

Ein separates QA-Team kann bei hoher Unabhängigkeit, vielen Produkten oder formalen Nachweisen sinnvoll sein. Für kleine, häufig geänderte Produkte kann eine QA-Fachkraft im Entwicklungsteam schneller Feedback geben. Der passende Zuschnitt hängt unter anderem von Auswirkung möglicher Fehler, Release-Rhythmus und nötiger Unabhängigkeit ab.

Division5 vermittelt Fachkräfte und kann ein Entwicklungsteam mit vereinbarten Rollen zusammenstellen. Sie können die geprüften Profile und aufgezeichneten Interviews schon vor dem Kennenlernen ansehen. Legen Sie fest, ob Qualitätssicherung als eigene Rolle enthalten ist und welche Prüfungen diese übernimmt. Für alle vermittelten Fachkräfte gilt eine 30-tägige Testphase; die Bedingungen werden für das jeweilige Angebot vor Beginn schriftlich festgehalten. Teamzuschnitt besprechen.