Die Automatisierung ist ein fortlaufender Prozess, der nie aufhört und immer verbessert werden kann.
Ihr solltet zunächst eine Priorisierung der Testfälle vornehmen und dann mit der Automatisierung der wichtigsten Fälle beginnen. Konzentriert euch zunächst auf die funktionalen Fälle. Zum Beispiel solltet ihr zuerst einen Basic procedure, einen Smoke-Test, einen Happy Flow usw. automatisieren.
Wenn alle wichtigen Testfälle automatisiert sind und der Prozess stabil ist, habt ihr Zeit, die restlichen Testfälle zu automatisieren, die weniger wichtig sind und eine geringere Auswirkung haben.
Selbst wenn ihr für die Automatisierung eines bestimmten Tests mehr Zeit aufwendet als für die manuelle Durchführung, werdet ihr langfristig mehr Zeit gewinnen, wenn dieser Testfall automatisiert ist.
Ich muss auch erwähnen, dass ihr euer Automatisierungsframework von Anfang an sorgfältig entwerfen solltet, damit es einfach zu warten ist und ihr keine Zeit verliert, wenn ihr versucht, das Framework in der Zukunft zu refaktorieren oder zu verbessern.
Es ist sehr aufwendig, Tests zu verwalten und zu priorisieren. Der Abdeckungsgrad ist einer von mehreren guten Näherungswerten.Eine Möglichkeit, Prioritäten zu setzen, besteht darin, mithilfe von Tools zu messen, welche Teile der Anwendung am häufigsten verwendet werden (was sich von der Abdeckung unterscheidet), und die Tests entsprechend zu konzentrieren, um diese Teile abzudecken.
Eine andere Möglichkeit ist die Verwendung von Expertenmeinungen und Faustregeln: Schreibt einen "Happy Path Test" für die aus Benutzersicht wichtigsten Funktionen und für Funktionen, die für die Sicherheit wichtig sind (die Kosten wären hoch, wenn euer Unternehmen wegen der Bereitstellung falscher Informationen verklagt würde). Messt die Testabdeckung und fügt weitere Tests hinzu, um sie zu erhöhen.
Die Abdeckung ist natürlich ein kompliziertes Thema (müssen eure Tests Fehlerbehandlungen abdecken, die selten und schwer auszulösen sind? usw.).Nach dem klassischen Ansatz solltet ihr die Kosten für die Durchführung automatisierter Tests als Investitionen betrachten und daher die Tests auswählen, deren Automatisierung euch einen maximalen ROI bescheren würde. (ROI = Return on Investment)
Die Herausforderung besteht hier in der Berechnung des NetProfit-Wertes, da dieser von eurem speziellen Projekt abhängt und davon, was ihr tatsächlich minimieren müssen (entweder die Kosten für das Testen oder die Testzeit).
Ihr solltet die durchschnittliche Anzahl der Builds pro Release, die Testprioritäten (die zu überarbeiten sind, da sich der Wert des Tests ändern kann), die Zeit für jede einzelne Testausführung und die geschätzte Zeit für die Implementierung und Wartung der Test- und Testausführungsumgebung berücksichtigen.
Dann sortiert eure Tests nach dem ROI-Wert (ROI = Return on Investment) und plant die Durchführung entsprechend den euch zur Verfügung stehenden Ressourcen.
Das Testen von Software ist in erster Linie eine risikobasierte Tätigkeit, sodass die Testfälle mit Bedacht für eine häufige Durchführung ausgewählt werden sollten, um mit möglichst geringen Investitionen eine maximale Rendite zu erzielen.
Es gibt hauptsächlich drei Arten von Testsuiten, die bei jeder Veröffentlichung einer Softwareanwendung ausgeführt werden: Regressionstests, veröffentlichungsspezifische Tests und Verifizierungstests zur Fehlerbehebung.
Ich würde die folgenden Testfälle als Teil der Regressionssuite auswählen:
- Fehler, die häufig aufgetreten sind: Einige Bereiche in der Anwendung sind so fehleranfällig, dass sie in der Regel nach einer kleinen Änderung des Codes fehlschlagen. Wir können diese fehlgeschlagenen Testfälle während des gesamten Produktzyklus im Auge behalten und sie in die Regressionstestsuite aufnehmen.
- die die Kernfunktionen der Anwendung überprüfen: Bevor ihr die Testfälle entwerft, identifiziert alle Kernfunktionen der Anwendung. Stellt sicher, dass die Testfälle alle im Anforderungsdokument genannten Funktionen abdecken. Man kann eine Rückverfolgbarkeitsmatrix verwenden, um sicherzustellen, dass keine Anforderung ungetestet bleibt.
- für Funktionalitäten, die in letzter Zeit Änderungen erfahren haben: Pflegt die Historie der Funktionsänderungen für die Testfalldokumentation, um die Testfälle zu identifizieren, die in die Regressionssuite aufgenommen werden sollen.
- Abdecken von Integrationsszenarien: Dazu gehören alle Integrationstestszenarien an der Funktionsgrenze, an der zwei Module miteinander kommunizieren und Daten weitergeben und die Integration stattfindet.
- die von Natur aus komplex sind: Einige Systemfunktionen können nur durch eine komplexe Abfolge von UI-Ereignissen erreicht werden.
- die eine hohe geschäftliche Priorität haben: Priorisiert die Testfälle in Bezug auf die Auswirkungen auf das Geschäft und auf kritische und häufig verwendete Funktionen. Es ist immer hilfreich, wenn eine Analyse durchgeführt wird, um festzustellen, welche Testfälle relevant sind. Eine Idee ist, die Testfälle nach Wichtigkeit und Kundennutzen in verschiedene Prioritäten einzuteilen. Durch die Auswahl von Testfällen nach Priorität lässt sich der Aufwand für Regressionstests erheblich reduzieren.
- Auf einer "Fall-zu-Fall"-Basis: Es bleibt immer Raum für Expertenurteile und Erfahrung, um Testfälle von Fall zu Fall auszuwählen, je nach Unternehmen/Domäne/Projekt/Team/Funktion usw.
Neueste Kommentare