Es gibt viele Faktoren, die darüber entscheiden, ob ein Test „gut“ oder „schlecht“ (nützlich oder nicht) ist – einige Beispiele sind:
- Ein Test ist eher gut, wenn er neue Informationen über die Leistungsfähigkeit der Software liefert.
- Die „Happy Path“-Tests, die ihr durchführt, wenn ihr neue Funktionen erforscht, sind weniger gut, sobald diese Funktionen stabil sind, können aber für die Regressionsprüfung nützlich sein.
- Tests für Wegwerf-Software (z. B. Proof-of-Concept-Anwendungen) sind wahrscheinlich weniger nützlich als Tests für Software, die eingesetzt werden soll.
- Tests für Szenarien mit hohem Risiko (d. h. mit einer hohen Eintrittswahrscheinlichkeit und großen Auswirkungen, falls sie eintreten) sind wahrscheinlich nützlicher als Tests für Szenarien mit geringem Risiko.
- Ein Regressionstest ist wahrscheinlich besser, wenn er Kernfunktionen oder Funktionen in den 20 % der Software abdeckt, die von 80 % der Benutzer verwendet werden.
- Ein Test ist wahrscheinlich nützlicher, wenn er das Benutzerverhalten widerspiegelt (vergesst nicht, böswilliges Benutzerverhalten in dieses Kriterium einzubeziehen).
- Ein Test ist eher nützlich, wenn er Teile der Anwendung abdeckt, die von anderen Tests nicht erfasst werden.
Abgesehen von den allgemeinen Grundsätzen gibt es eigentlich keine „harten“ Regeln. Moderne Software ist oft reaktionsschnell und nicht-deterministisch, sodass man das Verhalten nur für kleine Teilmengen der Gesamtfunktionalität vorhersagen kann (denn die gesamte Verhaltensmenge ist nahezu unendlich).
Ein erfahrener Tester wird sich ansehen, wie die Software verwendet wird, welche Probleme sie löst und für wen sie diese löst, und dementsprechend testen.
Jeder Test hat einen Wert und einen Preis. Sein Wert besteht in seiner Fähigkeit, Risiken zu verringern. Hier sind einige Möglichkeiten, wie ein Test wertvoll sein kann:
- Auswirkung. Das Aufspüren von Fehlern mit hoher Auswirkung ist wertvoller als das Aufspüren von Fehlern mit geringer Auswirkung, was wiederum wertvoller ist als das Nicht aufspüren, von Fehlern.
- Diagnostischer Wert. Ein Test, der die Ursache eines Fehlers eingrenzt, ist wertvoller als ein Test, der lediglich meldet, dass „etwas schiefgelaufen ist“.
- Konsistenz. Ein Test, der konsistente Ergebnisse liefert, ist wertvoller als einer, der inkonsistent ist.
- Erfolgsquote. Ein Test, der tatsächlich auftretende Fehler aufdeckt, ist wertvoller als ein Test, der Fehler aufdeckt, die nie aufgetreten sind.
Hier sind einige Möglichkeiten, wie ein Test teuer sein kann:
- Ressourcenintensiv. Ein Test, der viele Computerressourcen oder viel Geld erfordert, ist teurer als ein Test, der das nicht tut.
- Zeitintensiv. Ein lang laufender Test ist teurer als ein kurz laufender Test.
- Fragil. Ein Test, der viel Wartung erfordert, ist teurer als ein Test, den ihr nie aktualisieren müsst.
Wenn ihr den Wert und die Kosten eines Tests kennt, könnt ihr seine Güte beurteilen.
- Ein Test mit hohem Wert und niedrigen Kosten ist ein guter Test.
- Ein Test mit geringem Wert und hohen Kosten ist ein schlechter Test.
- Ein Test mit hohem Wert und hohen Kosten ist gerade noch in Ordnung. Ein Selenium-Test, der die gesamte Benutzeroberfläche abdeckt, aber einen hohen Wartungsaufwand erfordert, kann zum Beispiel gerade noch in Ordnung sein. Ihr könntet ihn in einen besseren Test verwandeln, indem ihr den Test (oder die Benutzeroberfläche) so umschreiben, dass der Test weniger anfällig ist.
- Ein Test mit geringem Wert und geringen Kosten ist einfach in Ordnung.
Dies ist eine schwierige Aufgabe, da sich Wert und Kosten im Laufe der Zeit ändern. Einige Tester empfehlen, Testsuiten regelmäßig zu überprüfen, um schlechte Tests zu entfernen oder neu zu schreiben. Auch das ist meine eigene Erfahrung, Test-Sets, Test-Pläne sollten immer wieder geprüft und upgedatet werden.
Weitere Merkmale von „guten“ Tests:
- Klare Anweisungen, wie und wann er ausgeführt werden soll
- Testet, ob das gewünschte Verhalten vorhanden ist
- Testet, dass unerwünschtes Verhalten nicht vorhanden ist
- Bietet eine gute Isolierung – wenn es fehlschlägt, wisst ihr, wo das Problem liegt!
- Basiert auf den Anforderungen und nicht auf der Implementierung.
- Ist wartbar und hat eine gute Rückverfolgbarkeit, sodass ihr bei Änderungen der Spezifikation diese schnell anpassen könnt.
- Keine falsch positiven oder negativen Ergebnisse – d.h. wenn der Test erfolgreich ist, ist das gewünschte Verhalten vorhanden und das unerwünschte fehlt, wenn er fehlschlägt, gibt es wirklich ein Problem.
- Liefert schnelle Ergebnisse zu geringen Kosten.
- Testet das wichtigste Verhalten zuerst
- Bricht entweder beim ersten oder zweiten Problem ab oder gibt laufend Rückmeldung über den bisherigen Status.
- Kann unterbrochen werden, liefert aber dennoch nützliche Ergebnisse, wenn auch nur teilweise
- Bietet eine gute Abdeckung des zu prüfenden Objekts, möglicherweise auf Kosten der zusätzlichen Zeit.
- Wird mit kostengünstigen, stabilen, langlebigen Tools mit guter Unterstützung implementiert
ist nicht plattformabhängig - Folgt anerkannten guten Praktiken für die Art der laufenden Prüfung
ist nicht-invasiv, d.h. kann ohne Änderungen am einsatzfähigen Code durchgeführt werden
Weitere Merkmale von schlechten Tests
- Ist undokumentiert oder kann nur vom Experten ausgeführt werden
- Stellt nicht sicher, dass das gewünschte Verhalten vorhanden ist
- Stellt nicht sicher, dass das unerwünschte Verhalten nicht vorhanden ist
- Basiert auf der Implementierung und nicht auf den Anforderungen
- Ist schwer zu pflegen und/oder lässt sich nicht zurückverfolgen, sodass ihr die Auswirkungen von Spezifikationsänderungen nicht kennt
- Sagt Ihnen, dass es ein Problem gibt, aber nicht was oder wo
- Wird manchmal bei schlechten Elementen akzeptiert und/oder versagt bei guten.
- Dauert lange und/oder ist mit hohen Kosten verbunden
- Gibt Ihnen bis zum Ende keine Ergebnisse oder Rückmeldungen (dann finden Sie vielleicht heraus, dass es vor 3 Wochen ein Problem gab, das hätte behoben werden können).
- Wenn Sie das Projekt unterbrechen, können Sie nicht feststellen, wie weit es fortgeschritten ist und welche Ergebnisse bisher erzielt wurden.
- Erfasst nur den/die „guten“ Pfad(e) durch den Code und bietet daher eine geringe Abdeckung.
- Hängt von teuren Tools ab, die hohe jährliche Kosten verursachen und sich schnell ändern
- Läuft nur auf einem bestimmten Rechner
- Entspricht keiner anerkannten Methodik
- Erfordert einen speziellen Build des Codes, der nicht mit dem Produktionscode übereinstimmt.
Neueste Kommentare