Unternehmen stehen für die Testautomatisierung ihrer Software meist vor der Wahl, sich ein Open Source Framework selbst zusammenzustellen oder die Limitierungen großer proprietärer Tools zu akzeptieren. Doch es gibt noch eine andere Möglichkeit.
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, aufwändig 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 Buildprozesse über Nacht laufen, deren Artefakte dabei automatisiert getestet werden.
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 Automationsframeworks, die zudem nicht selten in verschiedenen Programmiersprachen geschrieben sind, muss gelöst werden.
Es ist ein gewisser 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 aufwändig. Das wird dadurch verstärkt, dass regelmäßig mehr in die Kernfunktionalitäten und weniger in die Bedien- und Wartbarkeit des Tools investiert wird.
Eine Alternative ist der Kauf beziehungweise die Lizenzierung eines proprietären Tools. Solche „schlüsselfertigen“ Lösungen machen den aufwändigen Aufbau einer Testautomationslösung obsolet. Das Problem liegt hier in dem oftmals starren und beschränkten Funktionsumfang. Anpassungen des Tools sind entweder limitiert oder aber mit Aufwand verbunden, was neben den Lizenzkosten weitere Investitionen erfordert. Auch die Integration weiterer Tools ist bei proprietären Lösungen nicht selten problematisch.