{"id":700,"date":"2015-12-23T12:17:34","date_gmt":"2015-12-23T12:17:34","guid":{"rendered":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/?p=700"},"modified":"2024-02-26T09:30:36","modified_gmt":"2024-02-26T09:30:36","slug":"kochrezepte-fuer-testautomatisierung-teil-1","status":"publish","type":"post","link":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/kochrezepte-fuer-testautomatisierung-teil-1\/","title":{"rendered":"Kochrezepte f\u00fcr Testautomatisierung (Teil 1) \u2013 Suppe"},"content":{"rendered":"\n

Zutaten, K\u00fcchenger\u00e4te und wer ist der Koch?<\/strong><\/h2>\n\n\n\n

Ein Kollege sprach mich k\u00fcrzlich an und fragte, ob ich ein Rezept f\u00fcr eine gute Testautomatisierung kenne. Ich sagte, dass man daf\u00fcr \u2013 wie f\u00fcr eine gute Suppe \u2013 nicht nur ein Rezept braucht, sondern es kommt auf die Ausstattung der K\u00fcche, die Zutaten und den Koch an. Entscheidend f\u00fcr die Testautomatisierung sind also die Projektrahmenbedingungen, die Auswahl der Testwerkzeuge und die Tester die an der Testautomatisierung beteiligt sind.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
<\/div>\n\n\n\n

Wie k\u00f6nnen wir feststellen, ob die Rahmenbedingungen (nicht verwechseln mit Ramen<\/a>bedingungen) f\u00fcr die Testautomatisierung gegeben sind? Grundlegend ist hierbei zu unterscheiden, ob sich das Software-Projekt noch in der Vorplanung befindet und die Testautomatisierung von Anfang an eingeplant wird oder ob es sich um ein Projekt handelt, welches bereits l\u00e4uft und mit Testautomatisierung unterst\u00fctzt werden soll.<\/p>\n\n\n\n

Eines schon vorweg gesagt \u2013 je fr\u00fcher mit einer gut geplanten Testautomatisierung begonnen wird, desto wahrscheinlicher wird es eine erfolgreiche Testautomatisierung. Die Gr\u00fcnde liegen oft darin, dass die anf\u00e4nglichen Aufw\u00e4nde der Testautomatisierung untersch\u00e4tzt werden und sich der Nutzen rein rechnerisch erst nach Projektende einstellt.<\/p>\n\n\n\n

Um dem zu begegnen ist f\u00fcr ein beginnendes Projekt eine gute Planung und f\u00fcr ein laufendes Projekt erst einmal eine Vorstudie der laufenden Prozesse, Testf\u00e4lle und Rahmenbedingungen notwendig. In so einer Vorstudie sind unter anderem das bereits vorhandene Testfallportfolio, das Testobjekt und die Kenntnisse der Tester zu analysieren und zu bewerten. Auf diese Weise k\u00f6nnen wir erkennen, wo die eigentlichen Schwachpunkte des Projektes im Testbereich liegen.<\/p>\n\n\n\n

Oft wird versucht mit Testautomatisierung Probleme zu l\u00f6sen, die nichts mit der Testautomatisierung zu tun haben bzw. gegebenenfalls dadurch noch verschlimmert werden. Das ist wie beim Kochen, wenn die Suppe nicht schmeckt wird diese nicht zwingend besser, wenn wir einfach den Koch durch einen Automaten austauschen. Oft wird das Ergebnis sogar schlechter, wenn ich den Kaffeeautomaten im Flur betrachte. Wichtig ist, dass die Voraussetzungen f\u00fcr die Testautomatisierung eine Mindestqualit\u00e4t erreicht haben, bevor mit der Toolauswahl oder gar der Automatisierung begonnen werden kann. Die Testautomatisierung ist der Sahneklecks auf der Suppe, d. h. Testautomatisierung ist nur in einem gut funktionierenden Testprozess erfolgreich. Auch die Testf\u00e4lle m\u00fcssen eine ausreichende Detailtiefe zur Automatisierung haben. Die ben\u00f6tigte Detailtiefe ist davon abh\u00e4ngig in wie weit der Tester die n\u00f6tigen fachlichen Kenntnisse zum Testobjekt mitbringt. Hier k\u00f6nnte der eine oder andere auf die Idee kommen gleich die Fachseite \u2013 also die die das Fachwissen haben \u2013 die Testautomatisierung machen zu lassen. Das ist meist keine gute Idee, da den Mitarbeitern die Zeit fehlt. Zum einen steht ihre t\u00e4gliche Arbeit in der Priorit\u00e4t immer h\u00f6her als die Testautomatisierung und zum anderen m\u00fcssen die Toolkenntnisse und Testerfahrungen erst aufgebaut werden. Daher empfiehlt es sich, dass die Fachseite die manuellen Testf\u00e4lle in einer ausreichenden Detailtiefe liefert, welche der Tester auch ohne Domainwissen versteht. Anschlie\u00dfend nimmt der Tester mit seiner Testerfahrung und der n\u00f6tigen Toolkenntnis die Automatisierung vor.<\/p>\n\n\n\n

Es ist illusorisch alles automatisieren zu k\u00f6nnen, darum wird in der Vorstudie ein Priorisierung der Testf\u00e4lle vorgenommen. Dabei ist auch das Testobjekt bzw. die zu testende Software auf Automatisierbarkeit zu pr\u00fcfen. Besonders problematisch f\u00fcr die Testautomatisierung sind z. B. dynamische Objekt-IDs, die sich bei jedem erneuten Aufruf \u00e4ndern.<\/p>\n\n\n\n

Wie wir auch aus der K\u00fcche bereits kennen, ist dann auch noch der Koch wichtig, d. h. der Tester, der die Testautomatisierung durchf\u00fchrt. Zum einen ben\u00f6tigt dieser das n\u00f6tige Toolwissen und zum anderen muss er auch entscheiden k\u00f6nnen, wo sich die Testautomatisierung im Einzelnen lohnt. Zum Beispiel macht es keinen Sinn eine Funktion in der Software zu automatisieren, die nur extrem selten ben\u00f6tigt wird und im Automatisierungsaufwand sehr hoch ist.<\/p>\n\n\n\n

Darum sollte man sich immer an das Rezept halten:<\/p>\n\n\n\n