Antwort.

Das Definieren der Testgrenzen (scope) ist eine grundlegende Aufgabe für manuelles Testing, die es ermöglicht, sich auf die relevantesten und kritischsten Teile der Anwendung zu konzentrieren.

Hintergrund

Mit der Entwicklung von Projekten wächst das Volumen der zu testenden Funktionen, und das manuelle Abdecken aller Szenarien bleibt unmöglich. Mit dem Aufkommen von Agile/incrementeller Entwicklung hat die Rolle der Scope-Definition signifikant zugenommen.

Problem

Wenn die Testgrenzen unklar sind, besteht das Risiko:

Ineffizientes Testen durch Ressourcenverbrauch für unwichtige Funktionen
Kritische Bugs in wichtigen Szenarien zu übersehen
Überschneidungen mit der Arbeit anderer Tester, was Duplizierungen schafft

Lösung

Der Testscope sollte basierend auf:

Geschäftsprioritäten, Nutzer-Szenarien und Risiken
Anforderungen, Nutzer-Geschichten und Spezifikationen
Beratungen mit dem Team (Analysten, Produktmanager, Entwickler) definiert werden.

Schlüsselfunktionen:

Konzentration auf die wichtigsten Funktionen und Risikobereiche
Klare Festlegung/Dokumentation des Umfangs im Testplan, um Missverständnisse zu vermeiden
Möglichkeit, den Scope schnell zu überarbeiten, wenn sich die Anforderungen ändern

Fangfragen.

Muss man wirklich alles testen, was implementiert wurde, selbst die kleinsten Details?

Nein, das Prinzip des Testens ist die Fokussierung auf priorisierte und kritische Teile, besonders dort, wo am wahrscheinlichsten Fehler auftreten und Bugs erhebliche Auswirkungen auf das Geschäft haben.

Kann ein Tester den Scope selbständig erweitern oder einschränken, wenn neue Anforderungen aufkommen, ohne Rücksprache?

Nein, alle Änderungen im Scope müssen mit dem Produktmanager oder Teamleiter abgestimmt werden, um Lücken oder eine Duplizierung der Arbeit zu vermeiden.

Reicht es aus, sich nur auf technische Dokumentationen zur Definition des Scopes zu verlassen?

Nein, es müssen auch der Geschäftskontext, reale Nutzeraufgaben und Feedback vom Kunden berücksichtigt werden.

Typische Fehler und Anti-Patterns

Scope ist nicht festgelegt und ändert sich ständig
Ignorierung der Geschäftsprioritäten zugunsten nebensächlicher Funktionen
Fehlende Kommunikation zwischen den Teammitgliedern bei Änderungen der Testgrenzen

Lebensbeispiel

Negativer Fall

Der Tester beschließt eigenständig, alle Funktionen und Fälle abzudecken. Infolgedessen fehlt die Zeit zum Testen kritischer Wege, und die Hauptbugs entgehen.

Vorteile:

Formal wurden viele Szenarien getestet

Nachteile:

Kritische, blockierende Bugs bleiben unbemerkt aufgrund der Zerstreuung der Aufmerksamkeit
Verzögerungen aufgrund einer unberechtigt hohen Testlast

Positiver Fall

Zu Beginn des Sprints nimmt der Tester an der Planung teil, dokumentiert den Scope zusammen mit dem gesamten Team, fokussiert sich auf die wichtigsten Nutzer-Szenarien und stimmt den Arbeitsumfang ab und dokumentiert ihn in Confluence.