Testautomatisierung in der Entwicklung Software schneller bereitstellen durch Tests

Anbieter zum Thema

Hyland Software Germany GmbH

Für die Testautomatisierung von Software stehen Unternehmen vor der Frage: Ein Open-Source-Framework zusammenstellen oder Limitierungen proprietärer Tools akzeptieren? Doch mit dem passenden Tool lässt sich das Problem einfach lösen.

IT-Systeme leben: Diverse Anwendungen und Websites müssen stets neu getestet werden, um sicherzustellen, dass sie auch nach Veränderungen und Anpassungen funktionieren. Da sich diese Abläufe wiederholen, liegt eine Testautomatisierung nahe. Denn manuelles Testen immer gleicher Abläufe ist zeitintensiv, aufwendig und birgt ein erhebliches Fehlerpotenzial. Wenn die Automation mit einmaligem Mehraufwand aufgesetzt und eingerichtet wird, ist für jeden Testlauf sprichwörtlich nur noch ein Klick notwendig. Nach initialer Einführung erlaubt die Automation es, die Testabdeckung sukzessive zu steigern, die Time-To-Market zu verkürzen, und die Release-Frequenz zu erhöhen. Je häufiger ein Test durchgeführt werden muss, desto effizienter ist eine Automation.

Eine weitere Triebfeder für Testautomation ist der Druck, immer kürzere Entwicklungszyklen von Software zu realisieren. Software soll immer schneller live gestellt werden, wofür Ansätze wie Continuous Development und Continuous Integration entwickelt wurden. Hier hat sich der Standard herausgebildet, dass nach der Entwicklung am Tag automatisierte Build-Prozesse über Nacht laufen, deren Artefakte dabei automatisiert getestet werden.

Die zwei Welten der Testautomation

Testautomation benötigt Software, wobei Unternehmen entweder auf Open-Source oder auf proprietäre Lösungen zurückgreifen können. Es gibt zahlreiche Open-Source-Tools, die in der Regel darauf ausgerichtet sind, spezifische Systemkomponenten wie APIs und Weboberflächen zu testen beziehungsweise die Durchführung spezifischer Testarten wie Last- und Performance-Tests zu ermöglichen.

Unternehmen, die sich für den Open-Source-Ansatz entscheiden, stehen vor der Herausforderung, die passenden Tools auszuwählen und ihr Zusammenspiel zu orchestrieren. Unterschiedliche Tools, Bibliotheken und Frameworks müssen so integriert werden, dass sie gemeinsam zentrale Lösungen für Testablaufsteuerung, Testdatenhaltung, Reporting und Logging verwenden können. Auch das Problem der Übergabe von Daten zwischen den verschiedenen Komponenten des Automations-Frameworks, die zudem nicht selten in verschiedenen Programmiersprachen geschrieben sind, muss gelöst werden.

Es ist ein erheblicher Aufwand, ein solches Framework zu bauen und zu unterhalten, weil dazu Expertenwissen und Programmierkenntnisse notwendig sind. Hinzu kommt, dass oftmals nur eine Person im Unternehmen für die Testautomationslösung zuständig ist und ein Wissensmonopol aufbaut. Verlässt diese Person den Betrieb, ist sie kaum zu ersetzen.

Die Einarbeitung von Mitarbeitern in solche individuellen Testautomationslösungen ist aufwendig. Verstärkt wird das dadurch, dass regelmäßig mehr in die Kernfunktionalitäten und weniger in die Bedien- und Wartbarkeit des Tools investiert wird.

Eine Alternative ist der Kauf beziehungsweise die Lizenzierung eines proprietären Tools. Solche „schlüsselfertigen“ Lösungen machen den aufwendigen Aufbau einer Testautomationslösung überflüssig. Das Problem liegt hier im oftmals starren und beschränkten Funktionsumfang. Anpassungen des Tools sind entweder limitiert oder aber mit hohen Aufwänden verbunden, was neben den Lizenzkosten weitere Investitionen erfordert. Auch die Integration weiterer Tools ist bei proprietären Lösungen nicht selten problematisch.

Ein End-to-End Testautomations-Werkzeug

Das einzusetzende Testautomationswerkzeug sollte einen möglichst großen Funktionsumfang abdecken: Es sollte alle Bestandteile einer Anwendung inklusive Systemkomponenten wie Oberflächen (GUI), Datenbanken, Fileserver und APIs (zum Beispiel REST und SOAP) testen können. Ebenso sollte der Umgang mit Zertifikaten und Token, E-Mails und Dokumenten wie PDFs möglich sein. Das ist insbesondere dann von Bedeutung, wenn konsequent von Ende-zu-Ende getestet werden soll. Nur so lassen sich Sprünge zwischen verschiedenen Tools vermeiden.

Idealerweise sollte die eingesetzte Automationslösung auch für die Durchführung verschiedener Testarten verwendbar sein. Zum Beispiel können so bereits ausprogrammierte funktionale Tests auch für andere Testarten wie Last- und Performance Tests verwendet werden. Eine Flexibilität des Tools bezüglich des Einsatzes auf verschiedenen Teststufen wie Komponententests, Integrationstests und Systemtests sollte ebenfalls gegeben sein.

Die Notwendigkeit von Ad-hoc-Anpassungen

Änderungen am System unter Test (zum Beispiel neue Software-Features oder geänderter Tech-Stack) können Ad-hoc-Anpassungen am Testautomationswerkzeug notwendig machen. Mit einem Open-Source-Ansatz ist das grundsätzlich möglich, allerdings ist der Aufwand mitunter hoch und vor allem dann schwierig, wenn das Know-how zur Implementierung der Anpassungen ausgeschöpft ist. Klassische proprietäre Lösungen sind oftmals zu starr, um solche Anpassungen zu erlauben.

Ein geeignetes proprietäres Tool muss deswegen so offen sein, dass Anpassungen beziehungsweise projektspezifische Erweiterungen möglich sind, wenn die Built-in-Funktionalitäten nicht auf die Anforderungen vorbereitet sind. Jedoch erlauben die wenigsten proprietären Test-Tools solche Anpassungen und wenn doch, werden neue Features nicht auf der Stelle bereitgestellt. Gerade die großen Hersteller proprietärer Tools bieten keine Lösungen für Sonderfälle an. Wenn der Kunde Glück hat, erhält er ein Feedback auf seine Anfrage und sie wird in die Entwicklungs-Roadmap aufgenommen. Doch das löst sein Problem aber nicht.

Daher ist es vorteilhaft, wenn ein Anbieter sofort reagieren kann, die Machbarkeit prüft und das neue Feature als Patch auch neben Release-Zyklen zur Verfügung stellt. Anpassungen am Test-Tool können so bereits zeitnah bereitgestellt werden, und der Testablauf wird nicht blockiert.

Die Wartung von Testautomation

Was bei der Testautomatisierung gern vernachlässigt wird, ist die Wartung von Testskripten. Manche Methoden wie Capture and Replay, die bei der GUI-Automation zum Einsatz kommen, verursachen einen hohen Wartungsaufwand. Bei Capture and Replay wird ein Testfall manuell durchgeklickt, während das Test-Tool die verschiedenen Elemente identifiziert, und Algorithmen im Hintergrund Skripte erzeugen, die später zum Beispiel als Regressionstest verwendet werden. Auch wenn sich zunächst schnelle Erfolge in der Erstellung von Automationsskripten erzielen lassen, führt dieser Ansatz früher oder später zu Problemen. Änderungen am Layout der zu testenden Oberflächen oder Umbenennungen von IDs der UI-Elemente sind dann problematisch. Denn Tests müssen neu aufgezeichnet, oder vorhandene Skripte manuell angepasst werden. Der Aufwand, solche Tests zu stabilisieren, bremst den Fortschritt bei der Testautomatisierung.

Eine gute Automationslösung unterstützt den Anwender bei der Erstellung von Testfällen, die mit geringem Aufwand anpassbar sind. Entscheidend für eine gute Wartbarkeit von automatisierten Tests ist ein Testdaten-Management, das die Anpassung bestehender Tests vereinfacht. Zum Beispiel müssen Frontend-IDs nicht in jedem Skript, sondern nur einmal zentral geändert werden können. Server-Adressen und Zugangsdaten sollten auf globaler Ebene vorgehalten werden, während Testfall-spezifische Daten auf ihrer entsprechenden Ebene angelegt und gepflegt werden können. Dafür muss das Testdaten-Management differenziert, hierarchisch und mehrstufig aufgebaut sein.

Gute Automationslösungen sind zudem modular aufgebaut wie ein Baukasten, was die Kapselung von Daten und ein hohes Maß an Wiederverwendbarkeit von ausprogrammierten Funktionen ermöglicht.

User mit unterschiedlichem Know-how abholen

Testautomationstools werden von zwei Anwendertypen mit unterschiedlicher Expertise bedient: Der fachliche Experte kennt sich mit den Funktionen der zu testenden Software aus, aber nicht zwangsläufig mit der Automatisierung von Tests. Der technische Experte bringt als Entwickler oder Testautomatisierer Programmierkenntnisse mit. Idealerweise holt eine Testsoftware beide Benutzergruppen ab.

Für den Fachexperten muss ein grafisches Interface mit Drag-and-Drop-Elementen vorgehalten werden. Tests werden damit nach einem Baukastenprinzip aufgebaut. Die Parametrisierung der einzelnen Testschritte wird dafür idealerweise durch Wizards unterstützt.

Für technisch versierte Testautomatisierer sollte optional eine integrierte Entwicklungsumgebung (IDE) vorhanden sein, sodass sie in einer Programmierumgebung arbeiten oder in einem Texteditor coden können.

Sind beide Anwendertypen an der Testautomation beteiligt, kommt weder der fachliche noch der technische Aspekt zu kurz und es gelingt, alle verfügbaren Ressourcen in der Qualitätssicherung einzusetzen, und so die Testabdeckung und Qualität der Tests zu erhöhen.

Fazit

Ein Tool für Testautomation sollte auf verschiedenen Teststufen verwendbar sein. Es sollte alle Schnittstellen und Komponenten des Systems unter Test ansprechen können und ad hoc anpassbar sein, wenn Änderungen am System unter Test dies erforderlich machen. Nur so sind vollständige End-To-End-Tests der zu testenden Anwendung gut umsetzbar. Fehlen diese Eigenschaften, kommt es zu Lücken in der Testabdeckung oder zu Brüchen im Tooling, welche aufwendig geschlossen werden müssen. Das Testwerkzeug sollte zudem so aufgebaut sein, dass es einen geringen Aufwand in der Pflege der automatisierten Tests ermöglicht.

Der Autor: Dr. Robert Knack, ist Geschäftsführer der netqa GmhH.

(ID:50246069)