Hier erfahren Sie, wie Sie verschiedene Testtypen zu einer sinnvollen Strategie kombinieren, die zu Ihrem Projekt passt.
Willkommen zurück! Im vorherigen Artikel haben wir uns mit den verschiedenen Testtypen und ihren Inhalten befasst und die Definitionen der Testtypen erläutert. Erinnern Sie sich an dieses kleine Meme-Bild? Vielleicht haben Sie sich gefragt, wie all diese Testtypen, die Sie kennengelernt haben, zusammenarbeiten könnten.
Genau das lernen Sie als Nächstes. In diesem Artikel erfahren Sie, wie Sie diese Testtypen in sinnvolle Strategien kombinieren und eine auswählen, die zu Ihrem Projekt passt.
Sie können die Strategien mit verschiedenen Formen vergleichen, um ihre Bedeutung besser zu verstehen. Hier finden Sie eine Liste von Strategien mit den jeweiligen Größen und Entwicklungsbereichen.
Sehen wir uns die Strategien genauer an und erfahren wir, was hinter den Namen steckt.
Testziele festlegen: Was möchten Sie mit diesen Tests erreichen?
Bevor Sie mit dem Erstellen einer guten Strategie beginnen können, müssen Sie Ihr Testziel ermitteln. Wann sind Sie der Meinung, dass Ihre Anwendung ausreichend getestet wurde?
Eine hohe Testabdeckung wird von Entwicklern oft als ultimatives Ziel für Tests angesehen. Ist das aber immer der beste Ansatz? Bei der Entscheidung für eine Teststrategie sollte noch ein weiterer wichtiger Faktor berücksichtigt werden: die Bedürfnisse Ihrer Nutzer.
Als Entwickler verwenden Sie auch viele andere Anwendungen und Geräte. In dieser Hinsicht sind Sie der Nutzer, der darauf angewiesen ist, dass all diese Systeme „einfach funktionieren“. Im Gegenzug verlassen Sie sich darauf, dass unzählige Entwickler ihr Bestes tun, um ihre Anwendungen und Geräte zum Laufen zu bringen. Als Entwickler möchten Sie dieses Vertrauen auch erfüllen. Ihr erstes Ziel sollte also immer sein, funktionierende Software zu liefern und Ihren Nutzern zu dienen. Das gilt auch für die Tests, die Sie zur Gewährleistung der Anwendungsqualität schreiben. Kent C. Dodds fasst es in seinem Artikel Static vs Unit vs Integration vs E2E Testing for Frontend Apps (Statische vs. Unit- vs. Integrations- vs. End-to-End-Tests für Frontend-Apps) sehr gut zusammen:
Je mehr Ihre Tests der Art und Weise ähneln, wie Ihre Software verwendet wird, desto sicherer können Sie sein.
von Kent C. Dodds
Kent beschreibt es als Vertrauen in Tests gewinnen. Je näher Sie den Nutzern kommen, indem Sie einen passenden Testtyp auswählen, desto sicherer können Sie sich darauf verlassen, dass Ihre Tests gültige Ergebnisse liefern. Mit anderen Worten: Je höher Sie in der Pyramide klettern, desto selbstbewusster werden Sie. Aber was ist die Pyramide?
Teststrategien festlegen: Teststrategie auswählen
Legen Sie als ersten Schritt fest, welche Teile der Anforderungen Sie prüfen müssen, um sicherzustellen, dass sie erfüllt sind. Hier erfahren Sie, welche Testtypen Sie verwenden sollten und mit welcher Detailebene Sie die höchste Sicherheit bei gleichzeitig effizienter Kostenstruktur erreichen. Viele Entwickler nähern sich diesem Thema mithilfe von Analogien. Hier sind die gängigsten, beginnend mit dem bekannten Klassiker.
Klassiker: Die Testpyramide
Sobald Sie nach Teststrategien suchen, werden Sie wahrscheinlich als erste Analogie auf die Testautomatisierungspyramide stoßen. Mike Cohn hat dieses Konzept in seinem Buch „Succeeding with Agile“ vorgestellt. Später hat Martin Fowler das Konzept in seinem Artikel Practical Test Pyramid (Praktische Testpyramide) erweitert. Sie können die Pyramide visuell so darstellen:
Wie in dieser Abbildung dargestellt, besteht die Testpyramide aus drei Schichten:
Einheit Diese Tests befinden sich in der Basisschicht der Pyramide, da sie schnell ausgeführt und einfach zu pflegen sind. Sie sind isoliert und richten sich an die kleinsten Testeinheiten. Sehen Sie sich beispielsweise einen typischen Einheitstest für ein sehr kleines Produkt an.
Integration. Diese Tests befinden sich in der Mitte der Pyramide, da sie eine akzeptable Ausführungsgeschwindigkeit haben, Sie aber näher an die Nutzer heranbringen als die Unit-Tests. Ein Beispiel für einen Integrationstest ist ein API-Test. Sie können auch Komponententests als diesen Typ klassifizieren.
End-to-End-Tests (auch UI-Tests genannt). Bei diesen Tests werden ein echter Nutzer und seine Interaktion simuliert. Solche Tests benötigen mehr Zeit und sind daher teurer. Sie befinden sich an der Spitze der Pyramide.
Zuverlässigkeit im Vergleich zu Ressourcen
Wie bereits kurz erwähnt, ist die Reihenfolge der Ebenen kein Zufall. Sie zeigen die Prioritäten und die entsprechenden Kosten. So erhalten Sie einen klaren Überblick darüber, wie viele Tests Sie für jede Schicht schreiben sollten. Das haben Sie bereits bei der Definition der Testtypen gesehen.
Da End-to-End-Tests am ehesten den Nutzern entsprechen, können Sie mit ihnen am besten nachvollziehen, ob Ihre Anwendung wie vorgesehen funktioniert. Sie erfordern jedoch einen vollständigen Anwendungsstack und einen simulierten Nutzer und sind daher potenziell auch die teuersten. Die Zuverlässigkeit steht also in direktem Zusammenhang mit den Ressourcen, die Sie für die Durchführung der Tests benötigen.
Mit der Pyramide soll dieses Problem gelöst werden, indem Sie sich mehr auf Unit-Tests konzentrieren und die Fälle, die durch E2E-Tests abgedeckt werden, streng priorisieren. Beispielsweise die wichtigsten Nutzerpfade oder die Stellen, die am stärksten von Fehlern betroffen sind. Wie Martin Fowler betont, sind die beiden wichtigsten Punkte in Cohns Pyramide folgende:
- Schreiben Sie Tests mit unterschiedlicher Detailgenauigkeit.
- Je höher das Level, desto weniger Tests sollten Sie haben.
Pyramid hat sich weiterentwickelt! Anpassungen der Testpyramiden
Seit Jahren dreht sich die Diskussion um die Pyramide. Die Pyramide vereinfacht Teststrategien anscheinend zu sehr, lässt viele Testtypen aus und passt nicht mehr zu allen realen Projekten. Daher kann sie irreführend sein. Hat die Pyramide ihre Form verloren? Guillermo Rauch hat dazu eine Meinung:
Schreiben Sie Tests. aber nicht zu viele. Vor allem die Integration.
von Guillermo Rauch
Dieses Zitat wird häufig zu diesem Thema zitiert. Sehen wir uns das genauer an:
- „Tests schreiben“ Das stärkt nicht nur das Vertrauen, sondern spart auch Zeit bei der Wartung.
- „Nicht zu viele“. Eine Abdeckung von 100% ist nicht immer gut, da Ihre Tests dann nicht priorisiert werden und viel Wartung erforderlich ist.
- „Überwiegend Integration“ Auch hier liegt der Schwerpunkt auf Integrationstests: Sie bieten den größten Geschäftswert, da Sie täglich ein hohes Maß an Zuverlässigkeit bei einer angemessenen Ausführungszeit erhalten.
Das bringt Sie dazu, noch einmal über die Testpyramide nachzudenken und Ihren Fokus auf Integrationstests zu legen. In den letzten Jahren wurden viele Anpassungen vorgeschlagen. Sehen wir uns die gängigsten an.
Testdiamant
Bei der ersten Anpassung wird die übermäßige Betonung von Unit-Tests aufgehoben, wie in der Testpyramide dargestellt. Angenommen, Sie haben eine Abdeckung von 100% bei den Unit-Tests erreicht. Wenn Sie jedoch das nächste Mal eine Refaktorisierung durchführen, müssen Sie viele dieser Unit-Tests aktualisieren und sind möglicherweise versucht, sie zu überspringen. Sie erodieren also.
Infolgedessen und in Verbindung mit dem stärkeren Fokus auf Integrationstests kann sich die folgende Form ergeben:
Eine Pyramide entwickelt sich zu einem Rautenmuster. Sie sehen die drei vorherigen Ebenen, aber in einer anderen Größe. Die Einheitsebene wurde zugeschnitten:
- Einheit Schreiben Sie Unittests so, wie Sie sie zuvor definiert haben. Da sie jedoch dazu neigen, sich abzunutzen, sollten Sie nur die kritischsten Fälle priorisieren und abdecken.
- Integration. Die Integrationstests, die Sie kennen, testen die Kombination einzelner Einheiten.
- E2E. Diese Schicht verarbeitet die UI-Tests ähnlich wie die Testpyramide. Schreiben Sie nur End-to-End-Tests für die kritischsten Testfälle.
Wabenstruktur testen
Spotify hat eine weitere Anpassung eingeführt, die der Test-Diamant ähnelt, aber speziell auf microservicesbasierte Softwaresysteme ausgerichtet ist. Die Test-Wabe ist eine weitere visuelle Analogie für die Detaillierung, den Umfang und die Anzahl der Tests, die für ein mikrodienstbasiertes Softwaresystem geschrieben werden müssen. Aufgrund ihrer geringen Größe liegt die größte Komplexität eines Mikrodiensts nicht im Dienst selbst, sondern in der Interaktion mit anderen. Daher sollte sich eine Teststrategie für einen Mikrodienst hauptsächlich auf Integrationstests konzentrieren.
Diese Form erinnert an eine Bienenwabe, daher der Name. Es hat die folgenden Ebenen:
- Integrierte Tests Im Artikel von Spotify wird ein Zitat von J. B. Rainsberger: „Ein Test, der bestanden oder nicht bestanden wird, je nachdem, ob ein anderes System korrekt ist.“ Solche Tests haben externe Abhängigkeiten, die Sie berücksichtigen müssen. Umgekehrt kann Ihr System eine Abhängigkeit sein, die andere Systeme beeinträchtigt. Ähnlich wie bei End-to-End-Tests in anderen Analogien sollten Sie diese Tests mit Bedacht und nur für die wichtigsten Fälle verwenden.
- Integrationstests Ähnlich wie bei anderen Anpassungen sollten Sie sich auf diese Ebene konzentrieren. Sie enthält Tests, mit denen die Richtigkeit Ihres Dienstes in einer isolierteren Umgebung, aber immer in Kombination mit anderen Diensten überprüft wird. Das bedeutet, dass die Tests auch einige andere Systeme umfassen und sich auf die Interaktionspunkte konzentrieren, z. B. über API-Tests.
- Tests zu Implementierungsdetails Diese Tests ähneln Unit-Tests, bei denen sich der Fokus auf Codeteile richtet, die natürlich isoliert sind und daher ihre eigene interne Komplexität haben.
Weitere Informationen zu dieser Teststrategie finden Sie im Beitrag, in dem Martin Fowler die Testpyramide mit der Wabenstruktur vergleicht, und im Originalartikel von Spotify.
Test-Trophäe
Sie sehen bereits einen wiederkehrenden Fokus auf Integrationstests. Ein weiterer Testtyp, den Sie im vorherigen Artikel kennengelernt haben, ist kein Test im eigentlichen Sinne, aber dennoch ein wichtiger Aspekt, den Sie bei einer Teststrategie berücksichtigen sollten. Die statische Analyse fehlt in der Testpyramide und in den meisten der bisher gesehenen Anpassungen. Es gibt die Testtrophäen-Anpassung, bei der statische Analysen berücksichtigt werden, während der Schwerpunkt auf Integrationstests liegt. Die Testtrophäe stammt aus dem obigen Zitat von Guillermo Rauch und wurde von Kent C. entwickelt. Dodds:
Die Testtrophäe ist eine Analogie, die die Detailgenauigkeit von Tests auf eine etwas andere Weise darstellt. Sie besteht aus vier Ebenen:
- Statische Analyse: Sie spielt in dieser Analogie eine wichtige Rolle und ermöglicht es Ihnen, Tippfehler, Stilfehler und andere Fehler zu finden, indem Sie einfach die bereits beschriebenen Schritte zur Fehlerbehebung ausführen.
- Einheitentests. Sie sorgen dafür, dass Ihre kleinste Einheit angemessen getestet wird, werden aber in der Testtrophäe nicht in dem Maße hervorgehoben wie in der Testpyramide.
- Integration. Dies ist der Hauptfokus, da hier, wie bei anderen Anpassungen, die Kosten und die höhere Zuverlässigkeit am besten ausgeglichen werden.
- UI-Tests Dazu gehören End-to-End- und visuelle Tests. Sie befinden sich oben auf der Testtrophäe, ähnlich wie ihre Rolle in der Testpyramide.
Weitere Informationen zur Testtrophäe finden Sie im Blogpost von Kent C. Dodds zu diesem Thema.
Einige UI-orientierte Ansätze
Das ist alles schön und gut, aber ganz gleich, wie Sie Ihre Strategie nennen, ob „Pyramide“, „Bienenwabe“ oder „Diamant“, es fehlt immer noch etwas. Die Testautomatisierung ist zwar wertvoll, aber manuelle Tests sind immer noch unerlässlich. Automatisierte Tests sollten Routineaufgaben erleichtern und die Qualitätssicherungsmitarbeiter in die Lage versetzen, sich auf wichtige Bereiche zu konzentrieren. Automatisierung sollte manuelle Tests nicht ersetzen, sondern ergänzen. Gibt es eine Möglichkeit, manuelle Tests mit Automatisierung zu kombinieren, um optimale Ergebnisse zu erzielen?
Eiswaffel und Krabbe testen
Es gibt tatsächlich zwei Anpassungen der Testpyramide, die sich stärker auf diese UI-orientierten Testmethoden konzentrieren. Beide haben den Vorteil einer hohen Zuverlässigkeit, sind aber aufgrund der langsameren Testausführung natürlich teurer.
Die erste, die Test-Eiswaffel, sieht aus wie eine umgekehrte Pyramide. Ohne den Schritt für manuelle Tests wird sie auch als Testpizza bezeichnet.
Der Eiswagen legt einen größeren Fokus auf manuelle oder UI-Tests und am wenigsten auf Unit-Tests. Sie entsteht oft in Projekten, in denen die Entwickler mit nur wenigen Gedanken zur Teststrategie begonnen haben. Der Ice-Code gilt zu Recht als Anti-Muster. Er ist in Bezug auf Ressourcen und manuelle Arbeit kostspielig.
Der Testkrabbe ähnelt der Test-Eiswaffel, legt aber mehr Wert auf End-to-End- und visuelle Tests:
Diese Teststrategie umfasst noch einen weiteren Aspekt: Sie prüft, ob Ihre Anwendung funktioniert und gut aussieht. Der Testkrabbe wird die Bedeutung von visuellen Tests zugeordnet, die im vorherigen Artikel definiert wurden. Integrationstests, unterteilt in Komponenten- und API-Tests, treten weiter in den Hintergrund und Unit-Tests spielen hier eine noch untergeordnetere Rolle. Weitere Informationen zu dieser Teststrategie finden Sie in diesem Artikel zum Testkrabben-Prinzip.
Diese beiden Teststrategien sind zwar teurer, haben aber ihren Platz: beispielsweise bei kleineren Projekten, bei denen weniger Tests erforderlich sind oder weniger Komplexität abgedeckt werden muss. In diesem Fall ist eine umfassende Teststrategie mit Schwerpunkt auf Integrationstests möglicherweise zu aufwendig.
Diese beiden Teststrategien sind zwar teurer, haben aber ihren Platz, z. B. in kleineren Projekten, die weniger Tests erfordern und nicht sehr komplex sind. In diesem Fall kann eine umfassende Teststrategie, die sich auf Integrationstests konzentriert, unnötig komplex sein.
Praktische Tipps: Strategie entwickeln
Sie haben jetzt die gängigsten Teststrategien kennengelernt. Sie haben mit dem Klassiker begonnen – der Testpyramide – und sich mit ihren vielen Anpassungen vertraut gemacht. Jetzt müssen Sie sie für Ihr Produkt bewerten und entscheiden, welche für Ihr Projekt am besten geeignet ist. Die Antwort auf diese Frage sollte mit dem beliebten Es kommt darauf an beginnen. Das macht sie aber nicht weniger genau.
Die Auswahl der am besten geeigneten Teststrategie aus den beschriebenen – und auch aus den ausgelassenen – hängt von Ihrer Anwendung ab. Sie sollte zu Ihrer Architektur, Ihren Anforderungen und nicht zuletzt zu Ihren Nutzern und ihren Anforderungen passen. All das kann von Anwendung zu Anwendung variieren. Das ist völlig normal. Denken Sie daran, dass Ihr wichtigstes Ziel darin besteht, Ihren Nutzern zu helfen, nicht in einer Lehrbuchdefinition.
In der Praxis sind Tests oft schwer voneinander zu trennen und einzeln zu definieren. Sogar Martin Fowler selbst betont den positiven Aspekt unterschiedlicher Definitionen, z. B. im Fall von Unit-Tests. Wie Justin Searls in diesem Tweet richtig feststellt:
[…] aussagekräftige Tests schreiben, die klare Grenzen festlegen, schnell und zuverlässig ausgeführt werden und nur aus nützlichen Gründen fehlschlagen.
von Justin Searls
Konzentrieren Sie sich auf die Tests, bei denen tatsächliche Fehler gemeldet werden, die Nutzer möglicherweise finden, und lassen Sie sich nicht von Ihrem Ziel ablenken. Tests sollten für den Nutzer von Vorteil sein und nicht nur eine 100-prozentige Abdeckung bieten oder darüber entscheiden, welchen Prozentsatz welcher Testtyp ausmachen soll.
Konzentrieren Sie sich auf Tests, die reale Fehler melden, die Ihre Nutzer möglicherweise finden, und lassen Sie sich nicht von Ihrem Ziel ablenken. Tests sollten für die Nutzer von Vorteil sein und nicht nur eine 100-prozentige Abdeckung bieten oder Diskussionen darüber auslösen, welchen Prozentsatz eines bestimmten Testtyps Sie schreiben sollten.