Nach der Definition der Teststufen und insbesondere der Systemtests scheint es wichtig, einige sehr häufige Fallstricke zu erwähnen, über die unerfahrene Tester leicht stolpern können. Diese Fallstricke können unterschiedliche Auswirkungen haben, von Qualitätsverlust im Produkt bis hin zu geringerer Rentabilität von Investitionen in Tests. In jedem Fall können sich diese Praktiken für Unternehmen schnell als kontraproduktiv erweisen. 

Traps to avoid with system tests

1. Die „Black Box“ betreten 

Es kann manchmal verlockend sein, das System überprüfen zu wollen, um zu sehen, ob z. B. ein Element eingefügt wurde, aber seien Sie vorsichtig! Dieses „Eindringen“ in die Black Box erzeugt eine Abhängigkeit von der Implementierung des Systems und setzt es einer erhöhten Testwartung aus, wenn sich das System weiterentwickelt. Nur bei unbedingter Notwendigkeit und durch Abwägen der Vor- und Nachteile zu verwenden! 

2. Zum Durchführen der Tests vom ordnungsgemäßen Funktionieren des Systems selbst abhängen 

Dies ist der Fall, wenn wir die teilweise erhebliche Komplexität beim Aufbau des Testkontextes (Voraussetzungen für die Ausführung, Testdaten usw.) vermeiden wollen. Wir können uns dann dafür entscheiden, das System selbst zu nutzen, um in Form zu kommen, bevor wir mit unserem Test beginnen. Wir gehen das Risiko ein, eines der Ziele des Tests zu übersehen, das darin besteht, Informationen über das ordnungsgemäße Funktionieren des gesamten Systems zu liefern. 

Nehmen wir ein Beispiel:  

Wir möchten ein Feature überprüfen, um ein Element in einem System zu löschen. Um die Wiedergabefähigkeit des Tests zu gewährleisten, müssen wir über Daten verfügen, die bei jedem Start gelöscht werden müssen. Dann stehen uns mehrere Optionen zur Verfügung, darunter: 

  • Abspielen eines Skripts vor dem Starten des Tests zum Einfügen der Daten (in vielen Fällen die beste Option) 
  • Neuinstallation aller Testdaten bei jeder Bereitstellung des Systems und damit erneute Bereitstellung des Systems vor jedem Teststart 
  • „Ausreichend“ Daten haben, um den Test mehrmals durchzuspielen (diese Option ist eindeutig nicht die beste, weil sie das Problem nur verschiebt!) 
  • Einfügen der Daten mithilfe der Datenadditionsfunktion des Systems: Dies ist die Option, die einen großen Fallstrick ausblendet! 

Das Risiko besteht darin, die Sichtbarkeit des Status aller Systemfeatures zu verlieren, wenn das Einfügen von Daten nicht funktioniert.  

Datenbeschaffung, -änderung und -löschung können nicht mehr getestet werden, wenn alle Testszenarien mit dem Einfügen der Testdaten über das System beginnen und dies nicht möglich ist. 

Wir finden das gleiche Phänomen, wenn wir, um Zeit bei der Implementierung von Testkontexten zu sparen, ein „Super“-Szenario aufbauen, in dem wir alle zu testenden Funktionalitäten sorgfältig miteinander verknüpfen, um das Ganze abzudecken: Wir werden nur das erste aufgetretene Problem sehen können und wir werden blind für andere potenzielle Probleme sein, die später im Testszenario erkannt werden können. Wir setzen uns dann dem aus, was ich „Ketteneffekt-Bugs“ nennen würde: Wir beheben einen Fehler, wir entdecken den nächsten, wir beheben ihn, wir finden einen anderen usw. Und wir wissen absolut nicht, wie viele Funktionen des Systems in einem Moment T verändert werden. 

Dies macht die Entscheidungsfindung und Planung sehr schwierig, da der Korrekturaufwand nicht abschätzbar ist. Diese Abhängigkeit von der ordnungsgemäßen Funktion einiger Systemfunktionalitäten zur Validierung anderer ist unvermeidlich, muss aber mit Sorgfalt behandelt werden, und es ist wichtig, das Ziel des Tests nie zu verlieren: nämlich kontinuierliche Informationen über jede Funktionsregel des Systems bereitzustellen. 

3. Das Systemverhalten in Tests reproduziere

Es kann verlockend sein, einen Berechnungsalgorithmus zu reproduzieren, um beispielsweise die Relevanz des vom System zurückgegebenen Ergebnisses zu validieren. Aber diese Praxis ist sehr riskant und es gibt keine Möglichkeit zu sagen, ob das richtige Ergebnis dasjenige ist, das vom zu testenden System berechnet wurde oder dasjenige, das vom Testwerkzeug berechnet wurde. Ein häufiges Beispiel ist die Generierung von Authentifizierungstoken: Es ist nicht gut, zu versuchen, ein gültiges Token im Testtool zu berechnen, um das vom System zurückgegebene Token zu validieren. Der beste Weg ist immer noch, das empfangene Token zu verwenden, um seine Gültigkeit zu überprüfen (wobei darauf zu achten ist, nicht in den vorherigen Fehler zu tappen!). 

Achten Sie darauf, die Komplexität des zu testenden Systems nicht im Testwerkzeug selbst neu zu implementieren: Das Testwerkzeug muss „einfacher“ Beobachter des zu validierenden Systems bleiben, und das ist die ganze Schwierigkeit! 

4. „Eine Weile“ warten 

Wenn einige Systemprozesse „Zeit“ in Anspruch nehmen oder asynchron sind, sollten Sie eine „bestimmte Zeit“ abwarten, bevor Sie bestimmte Informationen überprüfen. Aber wie lange wird es dauern? 

  • Wenn wir zu kurz warten, wird der Test in die Irre geführt, wenn die Funktionalität ordnungsgemäß funktioniert. 
  • Wenn wir zu lange warten, wird die Testausführungszeit nach Abschluss der Verarbeitung durch das System verkürzt, was sehr schwerwiegende Auswirkungen haben kann, wenn wir Hunderte oder sogar Tausende von Tests durchführen.  

Oft müssen wir diese Wartezeit schrittweise verlängern, um Fehlalarme zu vermeiden und damit viel Zeit mit den Tests zu verschwenden. In dieser Situation können wir uns die Sekundärausgänge des Systems ansehen: Wir können das Erscheinungsbild eines Protokolleingangs oder die Emission einer bestimmten Benachrichtigung überprüfen, um den nächsten Schritt des Tests auszulösen. Es ist dann das System selbst, das uns sagt, wann wir weitermachen sollen. 

Es ist immer noch notwendig, sich für eine angemessene Zeitspanne zu entscheiden, um zu dem Schluss zu kommen, dass etwas schief gelaufen ist. Aber wenn der Test erfolgreich ist, werden wir die Wartezeit so weit wie möglich reduziert haben. 

5. Dynamische Referenzwerte verwenden 

Um die Tests durchzuführen, definieren wir „erwartete Daten“, die zur Validierung der Systemrückgaben verwendet werden. Wir müssen immer darauf achten, dass wir diese Daten nicht übermäßig dynamisieren: Wir können jederzeit Daten dynamisieren, die mit den aktuellen Daten verknüpft sind, oder die Beschränkungen der Einzigartigkeit bestimmter Informationen (z. B. generierte Leitfäden) in den Ausgaben, die wir überprüfen wollen, überwinden, aber wir müssen darauf achten, dass feste und kontrollierte Daten als Referenzwerte verwendet werden. Andernfalls besteht das Risiko darin, das Format oder die Struktur der Daten gut zu validieren, aber nicht ihre Wahrhaftigkeit, d. h. ihre Relevanz gegenüber dem Testdatensatz.  

6. Die Referenzdaten in Masse aktualisieren 

Dies kann oft dann getan werden, wenn sich die Ergebnisse des Systems erheblich ändern oder wenn Sie einen ersten Satz von Referenzdaten auf einem bestehenden System erstellen möchten. Sie müssen vorsichtig sein, da sich ein oder mehrere Fehler hinter dem aktuellen Feedback verstecken können. Wenn tatsächlich alles mit der aktuellen Änderung im System verbunden zu sein scheint, können eine oder mehrere Regressionen immer noch in den neu erhaltenen Rückgaben verborgen sein. Stammdaten werden lange Zeit zur Sicherung der Produktlieferung verwendet und die Einbettung eines Fehlers kann sich sehr stark auf die Kunden auswirken, ohne dass es jemand merkt.  

Referenzdaten müssen manuell und von Fall zu Fall validiert werden, um den bestmöglichen Nutzen aus Systemtests zu ziehen.  

7. Ein spezifisches Verhalten für Tests im System implementieren  

Dies ist der berühmte „If-Test“ im Produktionscode. Ein bestimmtes Verhalten wird ausgelöst, wenn ein bestimmter Header oder eine andere Information empfangen wird, um festzustellen, dass es sich um einen laufenden Test handelt. Dies ermöglicht es, das Verhalten des Systems zu validieren, wenn es Teil der Tests ist, aber nicht sein tatsächliches Verhalten in der Produktion. Ich muss zugeben, dass ich dies manchmal in ganz konkreten Fällen einsetzen musste, in denen es sich als wesentlich erwiesen hat, aber diese Praxis muss mit großer Vorsicht behandelt werden. 

8. Einen globalen Testbericht erstellen 

Je nach verwendetem Testtool können die verschiedenen Testfälle ausgeführt und Berichte auf unterschiedliche Weise generiert werden. Es ist wichtig, am Ende der Tests einen Bericht über den Status der einzelnen Systemfunktionen zu haben. Wir müssen vermeiden, dass ein einziger Indikator den globalen Status (der sehr oft „rot“ wäre) angibt und zur Konsole oder einer Datei gegangen werden muss, um das oder die aufgetretenen Probleme identifizieren zu können. 

9. Die Tests erst nach einer Systemänderung abspielen 

Es ist zwar wichtig, die Systemtests nach jeder Bereitstellung nach einem Systemwechsel abzuspielen, aber das reicht nicht aus. Es ist in der Tat wichtig, regelmäßig sicherzustellen, dass das System in seiner Umgebung funktionsfähig bleibt. Die Umgebung kann sich weiterentwickeln, und ein System, das nicht oft geändert wird, kann durch externe Ursachen verändert werden. Es ist daher ratsam, bestehende Tests regelmäßig zu initiieren, auch wenn keine Systemänderungen vorgenommen werden. Andernfalls besteht die Gefahr, dass bei der nächsten Änderung am System eine Reihe von Überraschungen auftauchen. 

10. Nur ausgelastete Fälle testen 

Während es unerlässlich ist, das ordnungsgemäße Funktionieren der Durchlauffälle eines Systems zu überprüfen, sind Fehlerfälle genauso wichtig, und manchmal sogar noch wichtiger, wenn wir an den nicht-funktionalen Merkmalen der Systemqualität wie Benutzerfreundlichkeit oder Sicherheit interessiert sind. Eine korrekte Information des Benutzers im Falle eines Missbrauchs des Systems verbessert beispielsweise die Qualität seiner Erfahrung. 

Zusammenfassung 

Sie sind wahrscheinlich bereits auf eine oder mehrere dieser Fallstricke gestoßen, und es geht immer darum, eine Entscheidung je nach Situation zu treffen. Wichtig bei der Risikobewertung oder Entscheidungsfindung ist es, so gut wie möglich zu wissen, welche Auswirkungen dies langfristig haben kann. 

In der Softwareentwicklung geht es beim Qualitätsmanagement vor allem um die Relevanz langfristiger Investitionen. Wenn Sie manchmal Entscheidungen treffen müssen, die die technische Verschuldung in Ihrem Produkt erhöhen, ist es kein Problem, solange Sie nicht vergessen, es so schnell wie möglich richtig zu verwalten. Aber dies kann das Thema eines anderen Artikels sein … 

Fotokredit: Michael Podger

Author

Mit über 10 Jahren Erfahrung mit Software-Testing-Strategie und Implementierungen in einem agilen Umfeld ist Alexandre dafür verantwortlich die Entwicklungen bei AT Internet voranzutreiben. Seine tägliche Herausforderung: Unsere Entwicklungsteams bei der Implementierung von Tools und Methoden anzuleiten. Das Ziel ist es regelmäßige Veröffentlichungen mit hoher Qualität für unsere Kunden zu garantieren.

Comments are closed.