Bringen Sie Ihre eigenen Werkzeuge mit… aber denken Sie vorher nach
Software-Teams haben heute mehr Freiheiten als je zuvor. Sie haben Zugang zu einer Vielzahl von Werkzeugen, und viele davon sind kostenlos. Es gibt eine Fülle an Open-Source-Bausteinen, mit denen sich Anwendungen erstellen lassen. Und das Beste: Viele Arbeitgeber ermutigen ihre Teams, eigene Entwicklungssysteme und Methoden einzurichten und dass Teammitglieder ihre eigenen Tools mitbringen.
Die Freiheit, die Werkzeuge, Methoden und Technologien zu nutzen, die Ihnen am meisten zusagen und die Sie am besten kennen, trägt wahrscheinlich positiv zur Produktivität Ihres Teams bei – bis zu dem Punkt, an dem die Selbstständigkeit des Teams an ihre Grenzen stößt.
Vermeiden Sie einen Test-Engpass
Mein Freund Jan leitete ein sehr kompetentes Softwareteam in einem individuellen Softwareentwicklungsunternehmen. Sie wussten wirklich, wie agiles Arbeiten funktioniert. Und sie hatten ein Qualitätsproblem. Sie beschleunigten ihren Release-Zyklus so sehr, dass das Testen zum Engpass wurde.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Und sie beseitigten den Engpass, indem sie die Tests einfach übersprangen. Jan wusste natürlich, was zu tun war. Er lud das Robot Framework herunter, nutzte es, um ein eigenes Testautomatisierungs-Framework für das Team zu bauen, und integrierte es in deren Continuous-Integration-Pipeline. Nach und nach fügte er immer mehr Tests hinzu und erweiterte das Framework mit einer großen Zahl an High-Level-Keywords, um das Test-Scripting zu erleichtern.
In der Zwischenzeit standen auch die anderen Teams – und es gab viele davon – vor ähnlichen Herausforderungen und lösten sie auf ihre eigene Weise, mit Selenium oder einem Tool ihrer Wahl.
Teams brauchen ein Automatisierungs-Framework für alle
Pessimisten sagen, dass jede Lösung schon den Keim eines neuen Problems in sich trägt. Jan merkte bald, dass er zum Vollzeit-Testautomatisierer geworden war. Natürlich waren seine Bibliotheken einfach zu benutzen – für ihn, und seine Testarchitektur war leicht zu verstehen – für ihn. In jedem anderen Team gab es einen Kollegen in derselben Situation. Einer davon wechselte den Job. Die Entwicklerin, die übernahm, entschied sich, alles neu zu schreiben, weil ihr die bestehende Automatisierung nicht gefiel und sie sie schwer verständlich fand. Als viele Teams dem Management diese Herausforderungen meldeten, stellte sich die offensichtliche Frage: Warum fehlt es an Konsistenz zwischen den Teams?
Es musste etwas geschehen. Die Lösung war offensichtlich: Wir gründen ein zentrales Testautomatisierungsteam, das die Entwicklungsteams mit einem gemeinsamen Automatisierungs-Framework unterstützt. In der Praxis bestand dieses Team aus Jan und einem weiteren Entwickler. Erst jetzt begannen die eigentlichen Schwierigkeiten.
Teilen Sie Methodik, nicht nur Tools
Die Tests waren häufig defekt. Ebenso das Framework. Die Entwicklungsteams taten sich schwer damit, ihre Arbeitsweisen auf die neue Tooling-Landschaft anzupassen, und das Tooling-Team konnte nicht alle unterschiedlichen Bedürfnisse abdecken. Die Komplexität des Frameworks wuchs stetig. Der Test-Engpass hatte sich zu einem Engpass im Testautomatisierungs-Tooling entwickelt.
Geteilte interne Tools sind eine schöne Idee, aber schwer umzusetzen. Damit es funktioniert, muss das Tool wie ein richtiges Produkt gemanagt und ordentlich getestet werden. Paradoxerweise sind Inhouse-Testautomatisierungs-Frameworks oft fehleranfällig. Doch es gibt eine noch größere Herausforderung: Um von gemeinsam genutzten Tools im großen Maßstab wirklich zu profitieren, braucht es auch eine gemeinsame Methodik.
Jans Geschichte ist typisch – und sie ist noch nicht zu Ende. Aktuell denken sie über die nächsten Schritte nach: Zurück zu autonomen Teams und die Kosten akzeptieren, mehr in das gemeinsame Tooling investieren und eine einheitliche Methodik schaffen oder ein kommerzielles Tool wählen und sich nur auf die Methodik fokussieren. Keine dieser Optionen ist falsch, aber jede wird unterschiedliche Konsequenzen haben.
