Zunächst einmal sind e2e-Tests aufgrund der vielen Schritte, die schiefgehen können, eher spröde.
Deshalb solltet ihr die Anzahl der e2e-Tests (und der UI-Tests im Allgemeinen) begrenzen. Denkt immer daran, dass ihr eine Testpyramide haben wollt, nicht die Test-Eistüte.
Aber für die Tests, die ihr automatisiert, kann die RCRCRC-Heuristik nützlich sein:
Quelle: Natürlich gilt dies für alle Tests, aber es ist ein Ausgangspunkt. Ich persönlich würde mit dem Produktverantwortlichen oder dem Business-Analysten sprechen, um zu erfahren, was die Kernfunktionalität der Anwendung ist, und mit anderen Testern, um herauszufinden, was die sich wiederholenden/langweiligen Teile des Tests sind (wie das Ausfüllen des Anmeldeformulars).
Die manuelle QA sollte einige Testszenarien enthalten, aus denen man schließen kann welche E2E manuellen Content haben und welche ohne großen Aufwand zu automatisieren sind. Immer eine Sache der Einordnung und der Prioritäten in eurem Team, man sollte nicht immer mit voller Kraft alles Automatisieren, was auch entsprechend viel Zeit benötigt, sondern entsprechend immer erst das Automatisieren, was am wenigsten Zeit verlangt.
- QA fragen, welche die meiste Zeit für manuelle Tests benötigen
- BA/SPO fragen, welche Teile der Anwendung/Funktionalität die größten Auswirkungen auf die Geschäftsseite/Endbenutzer haben
- das Entwicklungsteam fragen, welche Teile der Funktionalität am wenigsten mit Unit- und anderen Tests auf niedrigerer Ebene (in der Testpyramide) abgedeckt sind und welche Teile den meisten Spaghetti-Code und "monsters be here"-Code enthalten
- Auf der Grundlage dieser drei Kriterien den vorhandenen Testfällen einen numerischen Wert zuweisen (1-5 Punkte für jede Kategorie, wobei eine höhere Zahl bedeutet, dass eine Automatisierung notwendiger ist) und mit den am meisten geschätzten Testfällen beginnen (z. B. 15 oder 14 Punkte)
Neueste Kommentare