© DrHitch/Shutterstock.com
Shortcuts
Automatisiertes Testen

1 Automatisiertes Testen: ein Erfahrungsbericht

Insbesondere im agilen Umfeld mit kurzen Releasezyklen oder Continuous Delivery ist ein automatisierter Test fast unabdingbar. Hier ist es ohne immensen Testaufwand unmöglich, für jedes Release einen kompletten manuellen Regressionstest zu realisieren. JUnit-Tests haben für die Komponententests bereits vielfach Einzug gehalten. Geplante automatisierte Oberflächen- und Behaviour-Tests sind dagegen eher die Ausnahme.

Shortcut Autorenteam


Das strategische automatisierte Testen fristet in der Softwareentwicklung vielfach noch ein Schattendasein. Dabei ist es für wiederholbare Smoke- und Regressionstests sehr sinnvoll. Außerdem eignen sich nicht alle Tests und Prüfungen für menschliche Wahrnehmung und menschliches Verhalten, also für die manuelle Ausführung. Ungeeignet sind z. B. Prüfungen, bei denen Texte verglichen werden müssen, insbesondere wenn diese nicht in der Muttersprache sind oder darüber hinaus noch über ein anderes Alphabet verfügen. Auch wenn innerhalb eines großen Menüs ein Punkt fehlt oder Überschriften zwar vorhanden sind, aber den falschen Text haben, sind dies Punkte, die einem menschlichen Betrachter vermutlich nicht auffallen – wenn er nicht ausgerechnet danach sucht. Bei Anbietern automatisierter Testtools kommt das automatisierte Testen gerne wie eine Lichtgestalt daher. Entsprechend hochgeschraubte Erwartungen bauen sich auf. Unsere Anwendung läuft aktuell auf verschiedenen Plattformen (Multiplattform, Android/iOS, Desktop/Mobile) in zehn Übersetzungen (Multi Language) und auf vier unterschiedlichen Domänen (Multi Domain, COM Host, türkischer Host, brasilianischer Host, russischer Host). Anvisierte Wunschvorstellung war, für jeden Test bei dessen Aufruf festzulegen, auf welchen Plattform-Browser-Kombinationen (1 – x), für welche Sprachen (Angabe der zu prüfenden Sprachen, 1 – y) und für welche Domänen (1 – z) dieser laufen soll. In der vollen Ausprägung muss jeder Test x*y*z-mal laufen. Wie alles begannFolgende Ausgangssituation liegt vor: Für die vielen Workflows im Backend gibt es Unit-Tests. Improvements werden mit Features abgesichert, sodass sie leicht abgeschaltet werden können. Die Überprüfung der Anforderungen des Kunden bezüglich Aussehen und Verhalten der Anwendung wird manuell durchgeführt. Hierfür werden vom Kunden in den Implementierungs­tickets zusammen mit dem Entwickler Anforderungen und Abnahmekriterien definiert. Diese lassen sich von den Testern mit einem eigenen Schema in einen Testplan überführen, der manuell ausgeführt wird. Dieses Schema gibt Richtlinien für den manuellen Test vor, die neben explorativen Anteilen abgedeckt werden müssen. Beurteilt wird dabei neben der Spezifikation der Test für verschiedene Äquivalenzklassen, die Usability, das Design der Oberfläche und die Integration in das Gesamtsystem. Es gibt zurzeit keine automatisierten Tests, keine Last- und Performancetests und keine Penetrationstests.Abbildung 1.1 zeigt den Testabla...

Shortcuts
Automatisiertes Testen

1 Automatisiertes Testen: ein Erfahrungsbericht

Insbesondere im agilen Umfeld mit kurzen Releasezyklen oder Continuous Delivery ist ein automatisierter Test fast unabdingbar. Hier ist es ohne immensen Testaufwand unmöglich, für jedes Release einen kompletten manuellen Regressionstest zu realisieren. JUnit-Tests haben für die Komponententests bereits vielfach Einzug gehalten. Geplante automatisierte Oberflächen- und Behaviour-Tests sind dagegen eher die Ausnahme.

Shortcut Autorenteam


Das strategische automatisierte Testen fristet in der Softwareentwicklung vielfach noch ein Schattendasein. Dabei ist es für wiederholbare Smoke- und Regressionstests sehr sinnvoll. Außerdem eignen sich nicht alle Tests und Prüfungen für menschliche Wahrnehmung und menschliches Verhalten, also für die manuelle Ausführung. Ungeeignet sind z. B. Prüfungen, bei denen Texte verglichen werden müssen, insbesondere wenn diese nicht in der Muttersprache sind oder darüber hinaus noch über ein anderes Alphabet verfügen. Auch wenn innerhalb eines großen Menüs ein Punkt fehlt oder Überschriften zwar vorhanden sind, aber den falschen Text haben, sind dies Punkte, die einem menschlichen Betrachter vermutlich nicht auffallen – wenn er nicht ausgerechnet danach sucht. Bei Anbietern automatisierter Testtools kommt das automatisierte Testen gerne wie eine Lichtgestalt daher. Entsprechend hochgeschraubte Erwartungen bauen sich auf. Unsere Anwendung läuft aktuell auf verschiedenen Plattformen (Multiplattform, Android/iOS, Desktop/Mobile) in zehn Übersetzungen (Multi Language) und auf vier unterschiedlichen Domänen (Multi Domain, COM Host, türkischer Host, brasilianischer Host, russischer Host). Anvisierte Wunschvorstellung war, für jeden Test bei dessen Aufruf festzulegen, auf welchen Plattform-Browser-Kombinationen (1 – x), für welche Sprachen (Angabe der zu prüfenden Sprachen, 1 – y) und für welche Domänen (1 – z) dieser laufen soll. In der vollen Ausprägung muss jeder Test x*y*z-mal laufen. Wie alles begannFolgende Ausgangssituation liegt vor: Für die vielen Workflows im Backend gibt es Unit-Tests. Improvements werden mit Features abgesichert, sodass sie leicht abgeschaltet werden können. Die Überprüfung der Anforderungen des Kunden bezüglich Aussehen und Verhalten der Anwendung wird manuell durchgeführt. Hierfür werden vom Kunden in den Implementierungs­tickets zusammen mit dem Entwickler Anforderungen und Abnahmekriterien definiert. Diese lassen sich von den Testern mit einem eigenen Schema in einen Testplan überführen, der manuell ausgeführt wird. Dieses Schema gibt Richtlinien für den manuellen Test vor, die neben explorativen Anteilen abgedeckt werden müssen. Beurteilt wird dabei neben der Spezifikation der Test für verschiedene Äquivalenzklassen, die Usability, das Design der Oberfläche und die Integration in das Gesamtsystem. Es gibt zurzeit keine automatisierten Tests, keine Last- und Performancetests und keine Penetrationstests.Abbildung 1.1 zeigt den Testabla...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang