Automated Testing – das sagen unsere Frontend-Experten

Was bewegt die digitale Welt? Wohin entwickelt sich die Frontend-Technologie? Und was bedeuten die ganzen IT-Buzzwords eigentlich für die konkrete Projekt-Arbeit? Damit beschäftigen wir uns in der Reihe „Frontend Insights“: Insights unserer Kolleginnen und Kollegen von UX Design und Web Development bis Testing und Projektmanagement. Dieses Mal zum Thema „Automated Testing“.

404, drei Zahlen, die bei Entwicklern Angstschweiß auslösen. In der Testumgebung lief alles noch wunderbar, dann kam der Push in das Produktiv-System und plötzlich geht gar nichts mehr. Wie konnte das passieren?

Durch Automated Testing sollen Maßnahmen in den Produktionskreislauf eingebunden werden, die während der Entwicklung, vor dem Live-Gang und im laufenden Betrieb Warnungen und Hinweise liefern, damit sich Situationen wie oben nicht ereignen.

Wie der Name schon sagt, sollen diese Maßnahmen automatisiert durchgeführt werden, also durch Skripte und Programme. So erhoffen sich viele Entwickler, Zeit und Ressourcen einsparen zu können, die durch manuelles Testing entstehen würden.

Klingt zu schön, um wahr zu sein? Unsere Experten aus den Bereichen QA, Entwicklung und Sales gehen dem Thema “Automated Testing” auf den Grund.

Markus Meyer, Head of Quality Assurance, über Automated Testing:

„Automated Testing in der Software-Entwicklung bedeutet für mich: alle Maßnahmen zur Bewertung von Software, die nicht manuell durchgeführt werden. Von Health-Checks im Monitoring über Unit-Tests in der Entwicklung bis hin zu End2End-Tests durch Quality-Engineers. Ein weit verbreiteter Mythos ist, dass dadurch per se Ressourcen und Aufwand gespart würden. Das stimmt aber nur, wenn bereits ein entsprechender Aufwand in manuelle Qualitätsmaßnahmen gesteckt wird. Die Stärke automatisierter Testings liegt darin, dass sie die Aufwände für wiederkehrende Quality-Tätigkeiten minimieren und Ergebnisse schneller präsentieren können. Frei werdende Ressourcen werden dann sinnvollerweise in die Tätigkeiten transferiert, die ein noch höheres Qualitätsniveau bringen. Dann ist es langfristig billiger und besser. Dabei immer beachten: Was für den Computer richtig oder falsch ist, muss zuvor durch den User festgelegt werden. DON’T PANIC!“

Angelina Farsch, Sales Manager, über Automated Testing:

„Werden durch Automated Testing die laufenden Kosten geringer? Klares „Jein“! Durch Monitoring und Tools kann sichergestellt werden, dass die Webseite einer permanenten Überprüfung standhält. Damit wird der Aufwand aber nicht reduziert – höchstens beim Chef, der nicht jeden Morgen als erstes die Webseite auf Verfügbarkeit checkt. Es sorgt aber dafür, dass Ausfälle schneller bemerkt und behoben werden können. Bei immer komplexer werdenden Anwendungen wird das bald ein Must-have sein. Dabei ist der Automatisierungsgrad von Testing-Aktivitäten immer noch relativ niedrig. Manche Firmen führen deshalb ein Test-Excellence-Center ein, das als zentrale Instanz innerhalb des Unternehmens fungiert.“

Jörn Zaefferer, Head of Development (sloppy.io), über Automated Testing:

„Bei automatisiertem Testing besteht immer ein Risiko, es als Lösung für Probleme einzusetzen, die besser anders behoben würden. Zum Beispiel ist das automatisierte Testen von Benutzeroberflächen (im Browser oder in nativen Apps) sehr anspruchsvoll. Dort kann es wesentlich lohnender sein, auftretende Fehler aufzuzeichnen, zentral zu sammeln und zu analysieren. Ergänzt durch regelmäßige Usability-Tests (einem Anwender bei der Benutzung der Anwendung zuschauen) sind diese beiden Methoden oft wesentlich günstiger und effektiver als aufwändige automatisierte Tests, die gerne mal ohne erkennbaren Grund fehlschlagen.“

Manuel Schiller, Software Developer, über Automated Testing:

„Automated Testing hat sowohl Vorteile als auch Nachteile: Auf der einen Seite bietet es die Möglichkeit, wirklich End2End gegen eine API zu testen. Damit kann man zum Beispiel Änderungen an der API frühzeitig feststellen. Zudem kann man dadurch eine Webseite über mehrere Browser und Mobilgeräte stabil halten. Das ist vor allem dann wertvoll, wenn z.B. auf mobilen Geräten die nativen Inputs genutzt werden. Auf der anderen Seite ist die Gefahr hoch, „Umfaller“ in der Testbatterie zu haben, z.B. durch API-Ausfälle und lange Antwortzeiten. Außerdem sind die Testlaufzeiten hoch: Die Tests durchlaufen die Website wie ein User (Clicks, Tastenanschläge, Seitenaufbau). Damit benötigen sie ein Vielfaches der Zeit, die zum Beispiel bei SPA übliche Snapshot-Tests mit Jest oder ähnlichen Frameworks betragen würden.“

 

Weitere Themen der Reihe „Frontend Insights“:

Zur Blog-Startseite