Führung im Test: Wie viel Testen ist genug?
Hinweis der Redaktion: Willkommen zur Reihe Führung im Test von Softwaretest-Guru & Berater Paul Gerrard. Die Serie richtet sich an Tester mit einigen Jahren Erfahrung – insbesondere an diejenigen in agilen Teams – und soll helfen, in ihren Rollen als Testleiter und Testmanager zu glänzen.
Im vorherigen Artikel haben wir ein Risikomanifest für Manager vorgestellt. In diesem Artikel stellen wir die altbekannte Frage: "Wie viel Testen ist genug?" Spoiler: Das hängt von den Stakeholdern ab.
Melden Sie sich für den QA Lead Newsletter an, um benachrichtigt zu werden, wenn neue Teile der Reihe veröffentlicht werden. Diese Beiträge stammen aus Pauls Leadership In Test Kurs, den wir für einen tieferen Einblick in dieses und weitere Themen wärmstens empfehlen. Und denken Sie daran: Mit unserem exklusiven Gutscheincode QALEADOFFER erhalten Sie $60 Rabatt auf den vollen Kurspreis!
Wie viel Testen ist genug? Dies ist die klassische, unbeantwortbare, philosophische Frage, die sich alle Tester stellen, weil auch sie diese von ihren Stakeholdern gestellt bekommen.
Stakeholder möchten es wissen, weil sie die Gewissheit haben wollen, dass Systeme ausreichend getestet wurden. Da sie jedoch dafür bezahlen und Fristen einhalten müssen, wollen sie auch erfahren, welche Kosten beim Testen entstehen und wie lange es dauert.
Deshalb obliegt es den Stakeholdern zu entscheiden, wie viel getestet werden soll. Ihre Aufgabe als Testmanager ist es, ihnen dabei möglichst viel Mehrwert zu liefern, indem Sie sie bei der Entscheidungsfindung unterstützen. In diesem Artikel behandeln wir folgende Themen:
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
- Der Wert von Tests für Stakeholder
- Quantentheorie und die Theorie der Relativität (keine Physik)
- Die richtige Sprache verwenden
- Schätzungen, Budgets und Verhandlung
Fangen wir an.
Der Wert von Tests für Stakeholder
Jeder Test, den wir durchführen, sollte für Stakeholder einen Wert haben – nämlich als Beweis dienen, um deren Entscheidungsfindung in vier Bereichen zu unterstützen:
- Beweise, dass das System die Geschäftsziele des Projekts erfüllt.
- Beweise, dass das System nicht ausfällt, oder – falls doch – dass die Auswirkungen eines Ausfalls tragbar sind.
- Beweise zur Reproduktion und Diagnose von Fehlern sowie für die Reparatur und das erneute Testen des fehlerhaften Systems.
- Beweise, die Entscheidungsfindungen im Projektkontext unterstützen (z.B. zur Abnahme, Freigabe, Ablehnung etc.)
Unser Ziel beim Testen ist es, Tests zu entwerfen, die die Testabdeckung des Systems hinsichtlich eines erkennbaren Testmodells schrittweise erhöhen. Unsere Tests sollten zeigen, dass das System die Geschäftsziele erfüllt und dass das Ausfallrisiko bekannt und – hoffentlich – akzeptabel ist.
Von den vier oben genannten Arten von Beweisen bilden die ersten drei das Fundament für den vierten Punkt. Letztlich müssen Stakeholder eine evidenzbasierte Entscheidung treffen. Es ist ihre Entscheidung – nicht die der Tester. Deshalb liegt es an ihnen zu beurteilen, ob sie genug Vertrauen gefasst haben. Der Wert des Testens liegt also letztendlich im Auge des Stakeholders.
Jeder Tester wählt, was getestet wird, entweder auf Basis eines formalen Modells oder auch aus dem Bauch heraus. Diese Auswahl erfolgt aufgrund eines wahrgenommenen Nutzens.
Sofern der Tester nicht auch der Stakeholder ist, bewertet er den Nutzen meist anhand eines Grades von Vollständigkeit oder Abdeckung. Oder – falls die Interessen der Stakeholder bekannt sind – danach, ob der Test eine bestimmte Abnahmeentscheidung unterstützt.
Die obigen Grundsätze haben wichtige Konsequenzen.
Erstens: Wenn Sie die Einstellung des Stakeholders nicht kennen, wird Ihre Einschätzung des Testwerts wahrscheinlich von seiner abweichen. Wenn Sie Tests auswählen, ohne auf dessen Wertmaßstäbe Bezug zu nehmen, werden Ihre Stakeholder bei der Ergebnispräsentation womöglich feststellen, dass sie in manchen Bereichen zu wenig und in anderen zu viele Daten haben. Sicher ist: Sie werden sich nicht so sicher fühlen, wie sie es sollten.
Zweitens: Wenn Sie einen Test entwerfen oder durchführen, welchen Beitrag leistet er zur Entscheidungsfindung der Stakeholder? Wenn ein Test keine zusätzliche Information für eine Entscheidung liefert, oder wenn Stakeholder es gleichgültig ist, ob der Test besteht oder nicht, dann hat er in einem Testplan nichts verloren.
Wir sagten schon im dritten Artikel zu Modellen, dass die von Ihnen genutzten Testmodelle relevant für Stakeholder sein müssen. Wenn Ihre Testergebnisse auf Modelle abbilden, die Stakeholder verstehen und schätzen, so werden auch sie Ihren Beitrag schätzen.
Quantentheorie und die Theorie der Relativität
Es gibt zwei weitere Prinzipien, die sich auf den Wert und die Bedeutung von Tests beziehen. Das eine nenne ich die Quantentheorie und das andere die Theorie der Relativität. Diese Begriffe klingen hochtrabend (sie sind natürlich mit Augenzwinkern gemeint), beschreiben aber zwei Phänomene, die allen Diskussionen über Testwert, Priorisierung und Umfang zugrunde liegen.
Wenn wir einen Test durchführen, interpretieren wir das Ergebnis in der Regel als bestanden oder nicht bestanden. Die Bewertung „bestanden/nicht bestanden“ ist ein binäres Ergebnis – wahr oder falsch, ja oder nein, eine Eins oder eine Null. Dieses Testergebnis erzeugt eine diskrete Menge an Evidenz. Während wir immer mehr Tests ausführen, sammelt sich Evidenz an. Unabhängig vom Ergebnis erhöht dieser Test schrittweise die Abdeckung unseres Testmodells und unser Wissen über das Verhalten des Systems. Tests, die kein neues Wissen hinzufügen, bringen keinen Mehrwert.
Wenn ein Test die Abdeckung nicht auf irgendeine Weise schrittweise erhöht, hat er wenig Wert.
Der zweite Aspekt ist der Wert eines Tests. Was ist der Wert eines Tests? Könnten Sie wirklich einem einzelnen Test einen Dollar-, Pfund- oder Euro-Wert zuweisen? Wahrscheinlich nicht. Was wir aber tun können – und zwar oft recht einfach – ist zu sagen: „Dieser Test ist wertvoller als jener.“
Nehmen wir an, wir verwenden ein Codeabdeckungsmodell wie die Anweisungsabdeckung. Wir könnten einen Test durchführen, der fünf Codezeilen oder fünftausend Codezeilen ausführt. Was ist der Wert von jedem? Das ist schwer zu sagen. Aber wenn unser Ziel die Anweisungsabdeckung ist, hat der zweite Test einen höheren Wert.
Wir können keinem Test einen absoluten Wert zuweisen, aber wir können in der Regel Tests vergleichen und einen relativen Wert ableiten. Das heißt: Wenn wir unter Zeitdruck stehen, können wir meistens sagen, dass ein Test weniger wert ist als ein anderer, und daher ggf. den ersten Test aus dem Umfang nehmen, wenn es notwendig ist.
Wir können den Wert von Tests vergleichen, aber nur, wenn sie auf demselben Modell basieren.
Wir müssen jedoch betonen, dass diese Vergleiche wirklich nur dann sinnvoll sind, wenn sie das gleiche Modell teilen. Ein Test, der eine große Bandbreite extremer Bedingungen in einem Prozess abdeckt, hat vermutlich mehr Wert als ein Test des „geradlinigen“ Pfads. End-to-End-Tests eines komplexen Prozesses lassen sich zum Beispiel nicht direkt mit Unit-Tests kritischer Komponenten vergleichen.
Auch wenn die Theorien der Quantenphysik und der Relativitätstheorie nicht direkt auf das Testen anwendbar sind, gelten die Prinzipien von Anpassungsfähigkeit und Perspektive sehr wohl. Finden Sie ein Testmanagement-Tool, das mit diesen Prinzipien übereinstimmt, um Ihre Teststrategie zu optimieren.
Die richtige Sprache verwenden
Nachdem wir nun geklärt haben, wer dafür verantwortlich ist, zu entscheiden, „wie viel Testen genug ist“, stellt sich die Frage: Wie können wir als gewissenhafte Tester diese Entscheidungsfindung unterstützen?
Beachten Sie, dass unsere Behandlung des Werts von Tests unserer Risikobewertung sehr ähnlich ist. Wie im vorherigen Artikel bereits erläutert, ist es sehr schwierig, Risiken zahlenmäßig exakt zu beziffern. In der Regel ist es jedoch möglich, Risiken miteinander zu vergleichen und zu priorisieren, um festzulegen, welche Risiken beim Testen im Fokus stehen.
Wenn Tester die Sprache des Risikos verwenden, werden sie von der Geschäftsleitung wahrgenommen.
Leiter von Entwicklungsteams scheinen von Managern oft eher angehört zu werden, selbst wenn sie sich technisch ausdrücken. Der Unterschied ist, dass sie die Technologie als spannend und vorteilhaft präsentieren. Wenn Tester in ihrer eigenen Fachsprache sprechen – bei den „administrativen“ Details der Tests, wie etwa Störungsstatistiken – ist die Botschaft oft negativ, und Manager können gelangweilt oder genervt sein.
Das Management könnte ohnehin schon denken, dass Tester tendenziell etwas langweilig sind, aber das liegt vermutlich daran, dass viele Manager nicht wirklich verstehen, was Tester tun und welchen Wert sie schaffen. Tester sollten daher ihre Sprache auf Managementebene anheben.
Risikobasiertes Testen spricht die Nutzer- und Projektverantwortlichen in ihrer Sprache an.
Diese Leute denken sehr stark in Begriffen von Risiken und Nutzen. Wenn Tester sie auf diese Weise ansprechen, werden sie eher gehört und es werden bessere Entscheidungen gefällt. Indem wir Tests mit den Zielen des Projekts verknüpfen, lenken wir die Aufmerksamkeit auf die Ergebnisse mit dem größten Mehrwert für die Stakeholder, sodass wir unsere Testzeit für die wichtigsten Themen nutzen.
Sobald wir durch das Testen Fortschritte erzielen, können wir außerdem zeigen, dass die wichtigsten Vorteile jetzt verfügbar sind. Die Entscheidung für ein Release ist letztlich eine Abwägung, ob die Vorteile die Risiken überwiegen. Somit liefern Tests bessere Entscheidungsgrundlagen für das Management.
Verwenden Sie die Sprache des Risikos (und des Nutzens), um den Umfang festzulegen, zu planen und Fortschritte im Testprozess zu kommunizieren.
Natürlich müssen Tester technisch mit Entwicklern und anderem technischen Personal sprechen. Beispielsweise ist die Qualität von Störungsberichten ein Schlüsselfaktor dafür, Fehler schnell und zuverlässig zu korrigieren. Ich sage lediglich, dass der Tester, wenn er mit dem Management spricht, in Begriffen der adressierten und verbleibenden Risiken spricht – und nicht über Tests, Störungen und Fehler.
Schätzungen, Budgets und Verhandlungen
Gleich zu Projektbeginn fragt Ihr Projektleiter: „Ich muss die Tests rechtzeitig planen und Ressourcen zuweisen. Können Sie mir bitte abschätzen, wie viele Personen und wie viel Zeit Sie für die Systemtests benötigen?“
Sie machen sich Gedanken und gehen zum Chef.
„Ich brauche sechs Tester für acht Wochen.“
Der Projektmanager denkt einen Moment nach und schaut auf seinen vorläufigen Zeitplan sowie den Ressourcenplan.
„Du bekommst vier Tester für sechs Wochen, das ist alles.“
Du widersprichst und sagst: „Aber dann dauert es länger als sechs Wochen! Es wird mehr kosten, als du für das Testen dieses Systems eingeplant hast. Das System ist größer als beim letzten Mal. Es ist komplexer. Es ist diesmal auf jeden Fall zu riskant, beim Testen zu sparen. Das ist einfach nicht genug.“
Aber der Manager bleibt hartnäckig und murmelt etwas über andere Abhängigkeiten, höhere Instanzen und so weiter…
Welchen Sinn hatte es, eine Schätzung zu machen, wenn der Manager ohnehin schon wusste, wie hoch das Budget sein muss? Welche Relevanz hat ein willkürliches Budget für die eigentliche Aufgabe? Warum wird das Testen eigentlich nie ernst genommen? Die Entwickler bekommen doch immer die Zeit, die sie anfordern, oder? Das erscheint nicht fair.
Du fühlst dich vielleicht gekränkt und in deinem beruflichen Urteil untergraben. Aber das Problem ist und war immer, dass das Testbudget in dieser Situation festgelegt wurde. Alles, was du tun kannst, ist herauszufinden, welche Tests du mit deinem Budget am besten oder mit dem meisten Mehrwert durchführen kannst.
Oft will der Projektmanager aber tatsächlich wissen, wie lange etwas dauert, damit der Plan entsprechend angepasst werden kann. Wenn du denkst, dass du dich in einer Verhandlungssituation befindest, brauchst du Argumente zum Feilschen. Außerdem musst du die Ergebnisse des Plans diskutieren, nicht die Eingaben. Der Umfang ist ein Ergebnis der Planung, der Aufwand, den du einbringst, ist eine Eingabe.
Du musst über den Umfang verhandeln.
Die Verhandlung über Testbudgets sollte sich immer um den Umfang drehen, nicht um den Aufwand.
Der Umfang kann in einer oder mehreren Varianten dargestellt werden, und die Art und Weise, wie du den Umfang präsentierst und darüber sprichst, wird sich unterscheiden. Hier sind einige gängige Muster. Unabhängig davon, welchen Umfang du hast, nutzt du diesen als Grundlage für deine Schätzung und deren Verteidigung:
Umfang als Inventar von Anforderungen oder Features
Wenn die Schätzung um 30 % gekürzt wird, frage: „Welche 30 % des Systems soll ich nicht testen?“
Umfang als Inventar von Risiken
Wenn die Schätzung um 30 % gekürzt wird, frage: „Auf welche Stakeholder-Risiken soll ich im Plan verzichten?“
Umfang als tabellarisches oder grafisches Modell
Wenn die Schätzung um 30 % gekürzt wird, frage: „Welche Pfade/Reisen/Elemente soll ich den Stakeholdern nennen, die nicht getestet werden?“
Ich hoffe, du erkennst, worauf das Ganze hinausläuft.
- Der Testumfang basiert auf einem Modell, das zuerst mit den Stakeholdern diskutiert und vereinbart wurde. Dieser Umfang ist vorläufig und abhängig von den verfügbaren Ressourcen und der zur Verfügung stehenden Zeit, worauf du die Stakeholder hinweisen solltest.
- Du schätzt auf Basis dieses vorläufigen Umfangs. Nutze das Modell (Risiken, Anforderungen, Geschäftsprozesse oder ein anderes Modell), um ein Abdeckungsziel zu setzen, zähle die Abdeckungspunkte und schätze darauf basierend.
- Führe ein Gespräch mit dem Projektmanager. Ist die Schätzung zu hoch, nutze die obigen Formulierungen, um die Diskussion mit den Stakeholdern anzustoßen.
Als Tester oder Testmanager bist du nicht in der besten Position, über das Testen mit dem Projektmanager zu verhandeln. Die Stakeholder haben die eigentlichen Anliegen, und wenn du die Modelle teilst, die den Testumfang definieren, werden sie Meinungen dazu haben, sich mit dem Umfang identifizieren und diesen verteidigen. Die Stakeholder sind außerdem dafür verantwortlich, das Budget für ihr System zu rechtfertigen. Deshalb sind sie am besten positioniert, die Testkosten mit der Notwendigkeit, ihre Anliegen zu adressieren, abzuwägen.
Ein Denkanstoß
Überlege dir, wer in deinen Projekten die Verantwortung für das Ausmaß der durchzuführenden Tests übernimmt:
- Definierst du als Tester den Umfang und die Menge der Tests?
- Setzt der Projektmanager das Budget fest und du machst das Beste aus der dir zur Verfügung stehenden Zeit?
- Wird der Umfang mit dem Projektmanager und den Stakeholdern verhandelt, um ein Gleichgewicht zwischen Aufwand und tatsächlichem Testumfang zu finden?
Eine der wichtigsten Verantwortlichkeiten eines Testers ist es, dafür zu sorgen, dass das Projekt über die eingegangenen Produktrisiken informiert ist und sie zu dokumentieren. Nur wenn diese Risiken sichtbar sind, kann das Management erkennen, welches Risiko es eingeht, wenn beim Testen eingespart wird.
Es gibt keine Formel für die richtige Menge an Tests. In den meisten Umgebungen kann das Testniveau nur im Konsens zwischen Projektmanagement, Kundensponsoren, Entwicklern, technischen Spezialisten und den Testern festgelegt werden – Tests gelten dann als im Umfang enthalten, wenn sie die relevanten Risiken adressieren.
Ausreichend getestet ist, wenn dies im Konsens festgestellt wird – wobei der Tester den Konsensprozess unterstützt und Informationen beiträgt.
Melde dich zum QA Lead Newsletter an, um benachrichtigt zu werden, wenn neue Teile der Serie veröffentlicht werden. Diese Beiträge sind Auszüge aus Pauls Leadership In Test-Kurs, den wir sehr empfehlen, wenn du in dieses oder andere Themen tiefer eintauchen möchtest. Falls ja, nutze unseren exklusiven Gutscheincode QALEADOFFER, um $60 Rabatt auf den regulären Kurspreis zu erhalten!
Verwandte Artikel:
