Führung im Test: Modellierung und Abdeckung
In der Welt des Softwaretestens weiß effektive Führung, wie sie eine klare Richtung vorgibt, damit Teststrategien mit den Entwicklungszielen in Einklang stehen. Da Softwaresysteme immer komplexer werden, stoßen traditionelle Testmethoden zunehmend an ihre Grenzen.
Genau hier werden innovative Ansätze wie Testmodellierung und Abdeckungsanalyse entscheidend. Diese Praktiken stellen sicher, dass Teams sowohl kritische Pfade als auch Randfälle abdecken und ermöglichen bessere Zusammenarbeit, vermindertes Risiko und schnellere Auslieferung.
In diesem Beitrag beleuchten wir, was es bedeutet, mit Fokus auf Modellierung und Coverage zu führen. Wir erläutern, wie Testleiter diese Strategien nutzen können, um ihre Prozesse zu optimieren, die Produktqualität zu verbessern und für eine umfassende Testabdeckung zu sorgen – und dabei eine Kultur der Exzellenz und Verantwortlichkeit zu fördern. Ob Sie QA-Manager, Teamleiter oder einfach daran interessiert sind, Ihr Verständnis von Testführung zu vertiefen: Dieser Leitfaden bietet Ihnen praxisnahe Einblicke und Techniken, um Ihre Testaktivitäten auf das nächste Level zu bringen.
Los geht’s.
Was ist ein Testmodell?
Testen ist ein Prozess, bei dem wir mentale Modelle der Umgebung, des Programms, der menschlichen Natur und der Tests selbst erstellen. Jedes Modell wird entweder so lange verwendet, bis wir das Verhalten als korrekt akzeptieren, oder bis das Modell für den Zweck nicht mehr ausreicht.
Boris Beizer, Software Test Techniques, 1990
Testdesign ist der Prozess, bei dem wir aus der Vielzahl von Möglichkeiten die Tests auswählen, die uns und unseren Stakeholdern am wertvollsten erscheinen. Testmodelle helfen uns, Tests systematisch auszuwählen und sind grundlegend für das Testen.
So nutzen Tester Modelle:
- Wir identifizieren und untersuchen Wissensquellen, um Testmodelle zu erstellen.
- Wir nutzen diese Modelle, um unsere Quellen herauszufordern und zu validieren, wodurch sowohl unsere Quellen als auch unsere Modelle verbessert werden.
- Wir nutzen diese Modelle, um Testen und auch Entwicklung zu steuern.
Mit einer Testmission beginnen wir damit, die Wissensquellen zu identifizieren. Diese könnten sein:
- Dokumentation: Spezifikationen, Designs, Anforderungen, Standards, Richtlinien usw.
- Menschen: Stakeholder, Nutzer, Analysten, Designer, Entwickler und andere.
- Erfahrung: Ihre eigene Kenntnis und Erfahrung mit ähnlichen (oder auch unähnlichen) Systemen, Ihre Vorlieben, Vorurteile, Vermutungen, Ahnungen, Überzeugungen und Voreingenommenheiten.
- Neues System: Das zu testende System – sofern es existiert, verfügbar und zugänglich ist.
- Altes System: Das zu ersetzende System ist natürlich auch eine Quelle – es kann in bestimmten Funktionsbereichen als Referenz für erwartetes Verhalten dienen.
Es ist wichtig zu beachten, dass all unsere Wissensquellen fehlbar und unvollständig sind – und damit auch unsere Modelle. Tester setzen Erfahrung, Kompetenz und Urteilsvermögen ein, um diese Quellen zu sichten, zu vergleichen, zu hinterfragen und einen Konsens zu finden.
Alle Modelle sind falsch, einige sind nützlich
George Box, Ökonom.
Ein Testmodell könnte eine Checkliste oder eine Sammlung von Kriterien sein. Es kann ebenso ein aus einem Design-Dokument abgeleitetes Diagramm oder eine Analyse von erzählendem Text sein. Viele Testmodelle werden nie schriftlich festgehalten – sie existieren als mentale Modelle, die den Tester während der Erkundung des zu testenden Systems leiten.
Das Ziel von Modellen ist es, komplexe Sachverhalte zu vereinfachen, indem Details weggelassen werden, die zum aktuellen Zeitpunkt nicht relevant sind. Wir nutzen Modelle, um ein Problem zu vereinfachen – zum Beispiel bei der Auswahl dessen, was getestet wird. Das Modell prägt unser Denken, und wir wählen Tests, indem wir bestimmte Elemente oder Aspekte des Modells identifizieren.
Wir könnten Zweige in einem Flussdiagramm oder Kontrollflussdiagramm auswählen, Zustandsübergänge in einem Zustandsmodell, Grenzen in einem Modell einer Eingabe- (oder Ausgabe-)Domäne und Szenarien, die aus User Stories in der Gherkin-Domänensprache abgeleitet werden.
Aber Vorsicht: Manchmal enthalten Modelle Auslassungen, die problematisch sind – vielleicht vereinfacht das Modell eine Situation zu stark – und genau darauf sollten wir achten. Um Ihre Testmodelle effizienter zu gestalten, ist der Einsatz von spezieller Testmanagement-Software entscheidend.
Wenn wir keine Modelle direkt aus unseren Quellen erhalten, müssen wir sie erfinden. Werden Anforderungen z.B. als Fließtext geliefert, gilt es, mit der Sprache der Anforderungen Funktionen und deren Logik herzuleiten. Das ist für Entwickler wie für Tester oft schwierig und meist eine Teamaufgabe – aber notwendig.
Modelle zum Testen einsetzen
Wir verwenden Testmodelle, um:
- Vereinfachen Sie den Kontext des Tests. Irrelevante oder vernachlässigbare Details werden im Modell ignoriert.
- Lenken Sie die Aufmerksamkeit auf eine Perspektive des Systemverhaltens. Dies können kritische oder riskante Funktionen, technische Aspekte, interessante Benutzeraktionen oder Aspekte des Aufbaus oder der Architektur des Systems sein.
- Erzeugen Sie eine Reihe einzigartiger (im Kontext des Modells) Tests, die vielfältig sind (bezüglich dieses Modells).
- Ermöglichen Sie, dass das Testen geschätzt, geplant, überwacht und auf Vollständigkeit (Abdeckung) bewertet werden kann.
Aus Sicht des Testers hilft uns ein Modell dabei, Aspekte des Systems zu erkennen, die Gegenstand eines Tests sein könnten.
Modelle und Abdeckung
Abdeckung ist der Begriff, den wir verwenden, um die Gründlichkeit oder Vollständigkeit unseres Testens in Bezug auf unser Testmodell zu beschreiben. Ein Abdeckungselement ist etwas, das wir in unseren Tests ausüben möchten.
Idealerweise sollte unser Testmodell Abdeckungselemente auf objektive Weise identifizieren. Wenn wir geplante oder durchgeführte Tests haben, die Elemente abdecken, die unser Modell identifiziert hat, können wir die erreichte Abdeckung quantifizieren und diese als Anteil aller Elemente im Modell prozentual angeben.
Jedes Modell, das die Identifizierung von Abdeckungselementen ermöglicht, kann verwendet werden.
Modelle sind oft grafisch, beispielsweise als Flussdiagramme, Anwendungsfälle, Sequenzdiagramme und so weiter. Diese und viele andere Modelle bestehen aus Elementen (oder Blobs), die durch Linien oder Pfeile verbunden sind. Diese werden üblicherweise gerichtete Graphen genannt.
Stellen Sie sich ein grafisches Modell vor, das aus Blobs und Pfeilen besteht. Es könnten mindestens zwei Abdeckungsziele definiert werden:
- Abdeckung aller Blobs
- Abdeckung aller Pfeile
- Und so weiter
Daher kann jedes Modell, das ein gerichteter Graph ist, auf dieselbe Weise behandelt werden.
Ein formales Modell ermöglicht es, Abdeckungselemente zuverlässig zu identifizieren. Eine quantitative Abdeckungskennzahl kann daher definiert und als messbares Ziel verwendet werden.
Informelle Modelle sind oft Checklisten oder Kriterien, die dazu dienen, eine Liste von Abdeckungselementen zu brainstormen, Ideen für das Testen zu liefern oder in einer explorativen Testsitzung verwendet zu werden. Diese Listen oder Kriterien können vorab definiert oder als Teil eines Testplans erstellt oder in einer explorativen Sitzung angewendet werden.
Informelle Modelle unterscheiden sich von formalen Modellen darin, dass die Ableitung der Abdeckungselemente von der Erfahrung, Intuition und Vorstellungskraft des Praktikers abhängt, sodass die Abdeckung mit solchen Modellen niemals quantifiziert werden kann. Wir können niemals wissen, was vollständige Abdeckung im Hinblick auf diese Modelle bedeutet.
Tests, die aus einem informellen Modell abgeleitet wurden, sind genauso valide wie Tests aus einem formalen Modell, wenn sie unser Wissen über das Verhalten oder die Fähigkeiten unseres Systems erweitern.
Modelle vereinfachen, daher mehrere verwenden
Ein gutes Modell ermöglicht es, Komplexität zu verstehen und erreicht dies teilweise, indem es Details ausschließt, die nicht relevant sind. Ihr Modell könnte das Konzept von Zuständen, Fehlermodi oder Abläufen, Eingangskombinationen, Wertebereichen usw. verwenden.
Ein Modell allein reicht niemals aus, um ein System vollständig zu testen. Alle Modelle sind ein Kompromiss, daher benötigen wir mehrere Modelle. Dieses Konzept wird gewöhnlich als „Vielfalt von Halbmessungen“ bezeichnet. Das bedeutet, wir benötigen eine Vielfalt an Teilmodellen, um ein System angemessen zu testen.
Auch wenn sie nicht immer so bezeichnet werden, nutzen die Teststufen in klassischen Wasserfallprojekten Modelle aus unterschiedlichen Perspektiven. Unit-, Integrations-, System- und Benutzertests verfolgen verschiedene Ziele; jedes verwendet ein anderes Modell und eine andere Sichtweise – daraus entsteht die Vielfalt.
Modelle für das Management nutzen
Modelle stehen im Zentrum des Testens und auch des Testmanagements. Es gibt vier Schlüsselaspekte dazu:
- Einbindung der Stakeholder
- Umfang
- Abdeckung
- Schätzung und Fortschrittsüberwachung
Einbindung der Stakeholder
Wenn wir Tests planen, den Umfang festlegen und Stakeholdern den Fortschritt und die Bedeutung der Abdeckung erklären, müssen wir Modelle verwenden, die verständlich sind und sich an den Zielen der Stakeholder orientieren.
Wenn wir einen Benutzertest planen, werden wir wahrscheinlich den Geschäftsprozessfluss als unser Modell verwenden und als Vorlage, um Pfade nachzuvollziehen, die Systemfunktionen abdecken, die für den Benutzer wichtig sind. Wenn wir die Integration von Dienst-Komponenten im Auftrag eines technischen Architekten testen, nutzen wir das Architekturmodell, Kollaborationsdiagramme, Schnittstellenspezifikationen und so weiter als Grundlage für unsere Tests. Wenn wir Funktionen testen, die durch Nutzer definiert wurden, verwenden wir die User Stories, die Ergebnis vorangegangener gemeinsamer Anforderungsarbeit sind.
Wenn die Stakeholder Ihre Modelle nicht verstehen, werden sie Ihre Tests nicht verstehen, ihnen nicht vertrauen oder in diese investieren. Sie vertrauen möglicherweise nicht einmal Ihnen persönlich.
Scope-Management
Die erste Aktivität in einer Disziplin des systemischen Denkens besteht darin, eine Systemgrenze zu definieren. Beim Testen hilft Ihnen das erste definierte Modell dabei, den Testumfang festzulegen. Die nachfolgende Abbildung zeigt ein Schema der Systemarchitektur – ein „System von Systemen“ – in einer Organisation.
Jedes System (die konzentrischen Kreise) befindet sich in einem Anwendungsbereich wie CRM, Buchhaltung oder der Website. Alle Systeme und Anwendungsbereiche befinden sich innerhalb des „System von Systemen“. Natürlich enthält das Modell keine Detailinformationen, aber es ist klar zu erkennen, wie jedes System in die Gesamtarchitektur passt.
Wir könnten den Umfang unserer Tests beispielsweise leicht auf die ERP-Systeme beschränken.
Im zweiten untenstehenden Diagramm haben wir der Systemarchitektur weitere Details hinzugefügt und drei Möglichkeiten skizziert, wie wir den Geltungsbereich noch spezifischer definieren könnten.
- Die gelb markierten Systeme sind die sogenannten Systeme der Aufzeichnung. Diese Systeme können beispielsweise eine Datenbank gemeinsam nutzen und Änderungen am Datenbankschema könnten sich nachteilig auf alle diese Systeme auswirken – und somit in den Testumfang fallen.
- Die Systeme, die von der lilafarbenen Linie eingeschlossen werden, teilen möglicherweise eine gemeinsame Funktionalität oder Infrastruktur – vielleicht nutzen sie alle einen gemeinsamen Satz von Webservices, das gleiche Messaging-System oder laufen auf demselben Server.
- Die gestrichelte blaue Linie markiert eine Benutzerreise, die die durch die Linie verbundenen Systeme nutzt. Vielleicht hat sich diese Benutzerreise geändert und unser Fokus liegt auf der Konsistenz und Genauigkeit des Datenflusses zwischen diesen Systemen.
Ein Modell kann zeigen, was im Testumfang ist, aber ebenso wichtig ist es zu zeigen, was nicht im Geltungsbereich liegt.
Ein Modell hilft, den Testumfang zu definieren, und erlaubt es außerdem, den Umfang den Stakeholdern in verständlichen, nachvollziehbaren und (hoffentlich) akzeptierten Worten zu erklären.
Wenn wir ein Modell zur Definition des Scopes verwenden, definiert das Modell das Gebiet und die im Scope liegenden Elemente kennzeichnen die Orte, die wir erkunden und testen möchten.
Coverage-Management
Die Messung der Coverage kann helfen, Tests überschaubarer zu machen. Wenn wir kein Konzept von Coverage haben, können wir Fragen wie „Was wurde getestet?“, „Was wurde nicht getestet?“, „Sind wir fertig?“, „Wieviele Tests stehen noch aus?“ möglicherweise nicht beantworten. Für einen Testmanager ist das besonders unangenehm.
Die zu erzielende Coverage ist der logische nächste Schritt, sobald der Scope definiert ist.
Wir nutzen das Scope-Modell, um die Orte zu definieren, die wir testen werden. Unser Coverage-Modell zeigt den Stakeholdern, wie gründlich wir an diesen Orten testen werden.
Testmodelle und Coverage-Maße können verwendet werden, um quantitative oder qualitative Ziele für die Testgestaltung und -durchführung festzulegen. In unterschiedlichem Maße können wir solche Ziele zur Planung und Schätzung nutzen. Wir können außerdem den Fortschritt messen und auf die Gründlichkeit oder Vollständigkeit der geplanten oder durchgeführten Tests schließen. Allerdings müssen wir mit allen quantitativen Coverage-Maßen oder Prozentsätzen, die wir einsetzen, sehr vorsichtig umgehen.
Eine Coverage-Messung (basierend auf einem formalen Testmodell) kann zwar objektiv berechnet werden, aber es gibt keine Formel oder Gesetzmäßigkeit, die besagt, dass X Coverage Y Qualität oder Z Vertrauen bedeutet. Sämtliche Coverage-Maße liefern nur indirekte, qualitative und subjektive Erkenntnisse über die Gründlichkeit oder Vollständigkeit unserer Tests. Es gibt keine sinnvolle Beziehung zwischen Coverage und Qualität oder Akzeptanz von Systemen.
Quantitative Coverage-Ziele werden häufig genutzt, um Abschlusskriterien für die Fertigstellung von Tests zu definieren, diese Kriterien sind jedoch willkürlich. Ein strengeres Coverage-Ziel könnte doppelt so viele zu prüfende Elemente generieren. Dennoch machen doppelt so viele Testfälle zu doppelten Kosten ein System weder doppelt so getestet noch doppelt so zuverlässig. Eine solche Deutung ist sinnlos und leichtfertig.
Manchmal werden die formalen Modelle, die zur Definition und Entwicklung eines Systems verwendet werden, den Testern vorgegeben, damit sie diese zur Festlegung von Abdeckungszielen nutzen. In anderen Fällen stehen den Testern nur wenige Dokumentationen zur Verfügung, sodass sie eigene Modelle erfinden müssen. Die Auswahl jedes Testmodells und Abdeckungsziels ist in gewissem Maße willkürlich und subjektiv. Folglich können informelle Testmodelle und Abdeckungsmaße genauso nützlich sein wie etablierte, formale Modelle.
Schnelle Modellierungsübung
Eine kurze Übung zum Abschluss. Erstellen Sie zu den folgenden Beispielen eine Skizze davon, wie das Modell Ihrer Meinung nach aussehen könnte – lediglich die Form –, entweder als Bild/Diagramm, Tabelle oder Liste:
- Nutzer sind an den End-to-End-Prozessen im System interessiert.
- Ein Nachrichtendienst kann sich in vier Zuständen befinden: ausgeschaltet, laufend, startet und fährt herunter.
- Ein Versicherungsbeitragsrechner hat 40 Eingabewerte, die in Kombination die Berechnung beeinflussen; es gibt Abhängigkeiten zwischen einigen Eingaben.
- Ein Extrahieren/Transformieren/Laden-Prozess besteht aus sieben Stufen. Nach der Extraktion werden Datensätze entweder abgelehnt, in eine Wartedatei übertragen oder transformiert und an die nächste Stufe weitergeleitet. Die letzte Stufe ist ein Ladeprozess, der Ablehnungen behandelt. Überprüfen Sie, dass alle extrahierten Datensätze erfasst werden.
Abonnieren Sie den Newsletter des CTO Club für weitere Einblicke ins Testen!
