Testautomatisierung - Von Unit bis System, von Theorie zu echter Praxis

Die Produktivität in Teams leidet oft unter falschen oder verzerrten Wahrnehmungen der jeweils anderen Stakeholder. Wir beschreiben einen Fall, in dem ein dysfunktionales Team durch Erhebung von Reifegradmessungen und anschließender konsensorientierter Diskussion wieder erfolgreich wurde.

Testautomatisierung gehört heute zum Standard-Repertoire jeder IT-Organisation. Doch das Versprechen von „Agilität durch Automatisierung“ schlägt in der Praxis oft ins Gegenteil um: Historisch gewachsene UI-Suiten blähen die Pipeline auf, Builds sind „rot“, ohne dass ein echter Produktfehler vorliegt, und Teams verbringen mehr Zeit mit dem Reparieren von Skripten oder Modellen als mit der Qualität..

Jetzt fragen wir uns schon, wieso man überhaupt Architekten braucht und dann jetzt auch noch Test-Architekten? Und ja, man braucht beide und der Artikel zeigt, wieso und was der Vorteil ist.

ERP-Migrationsprojekte erhöhen den Testdruck massiv: neue Funktionen, Datenmigration, Schnittstellen, enge Release-Zyklen und meist hohe fachliche Risiken. Der Beitrag zeigt aus der Praxis, wie Testautomatisierung (TA) in einem solchen Umfeld funktioniert: nicht als Selbstzweck, sondern als Ergebnis einer klaren Testautomatisierungsstrategie und einer risikobasierten Auswahl der richtigen Szenarie..

Viele gängige Verfahren aus dem Testdatenmanagement stellen Testdaten für Tests bereit. Diese Testdaten sind aber typischerweise nicht auf die konkreten, spezifischen Bedürfnisse der einzelnen Tests abgestimmt. Dies führt insbesondere im Umfeld von Testautomatisierung und CI/CD-Pipelines zu diversen Problemen, die ein radikaler Testdaten-Engineering-Ansatz weitgehend entschärfen kann.