Wie kann man eine gigantische Test-Suite mit 80.000 Tests effizient nutzen? Dr. Bernd Vogel (ATOSS Software AG) hat für die Digital-Workforce-Management-Software “ASES” einen Weg gefunden: die Test-Impact-Analyse von Teamscale.

Lesen Sie mehr über die Hintergründe, das Vorgehen und die Herausforderungen im Interview mit Dr. Sven Amann – oder sehen Sie Dr. Bernd Vogel in der Aufzeichnung des Software Intelligence Talks zusammen mit Raphael Nömmer!

Sven: Ist für deine jetzige Rolle ein ganzheitlicher Blick auf das System entscheidend?

Bernd: Auf jeden Fall. Wir schreiben bei der ATOSS schon seit 2004 für jede neue Entwicklung und jeden gelösten Bug einen automatisierten Test. Aber damit alleine erwischt man oft nicht alles, weil man funktional eher an einer Stelle ist. Meine Aufgabe war deshalb, Änderungen zusätzlich manuell zu testen und dabei braucht man diese Kreativität eines Anwenders, der weiß: “Aha, dort ist noch dies und das, und da ist noch ein Schalter – spielt das richtig zusammen?” Ich wurde damit zur Keimzelle eines Testteams, das jetzt 20 Leute umfasst und das Gesamtsystem im Blick hat.

Aber ich würde deshalb auf automatisiertes Testen nicht verzichten wollen! Erst wenn man beides zusammen legt, das automatisierte Testen und den kreativen Prozess, dann hat man eine gute Chance, ein Qualitätslevel zu erreichen, das hoch ist und auch dort bleibt. 

Sven: Ihr wart also sehr früh dabei beim Automatisieren von Tests?

Bernd: Es war die natürlichste Entscheidung für die Firma damals. Manuelles Testen ist gut und schön, das findet die wüsten Dinge und auch exotische. Aber um die Qualität aufrechtzuerhalten, brauche ich einen großen Satz an automatisierten Tests, der sicherstellt, dass ungewollte oder unüberschaubare Änderungen im Code auffallen. Unsere inzwischen 80.000 Tests zu betreiben ist zwar einerseits lästig, gibt aber andererseits sehr viel Sicherheit. Das ist unglaublich wertvoll! Und all die Maschinen und die Laufzeit der Tests sind so viel billiger, als die Fehler, die jetzt schon intern gefixt werden, erst beim Kunden zu finden. 

Sven: 80.000 Tests zu haben ist ja eine besondere Situation, denn es ist eine vergleichsweise sehr umfangreiche Test-Suite. Habt ihr uns (die CQSE) deshalb als erstes für Testlaufzeitoptimierung durch die Test-Impact-Analyse an Bord geholt?

Bernd: Es gab zwei Auslöser. Ein Kollege hatte mit Elmar Jürgens, einem der CQSE-Gründer, studiert und kannte die CQSE daher schon. Er hat eine Vorstellung von Teamscale, als Tool für Code-Qualität, bei der ATOSS organisiert. Und dann kam noch ein CQSE-Workshop dazu, bei dem das Feature Test-Impact-Analyse vorgestellt wurde. Anschließend war schnell entschieden, dass wir Teamscale haben wollen.

Wir konnten damals die Tests auf der CI nicht schnell laufen lassen, weil die Bauzeit der ASES einfach zu lang war. Deshalb wollten wir die einzelnen Entwickler*innen in die Lage versetzen, schnell die richtigen Tests zu ihren lokalen Änderungen zu finden und auszuführen. Und das hat gut zur Test-Impact-Analyse gepasst, auch wenn klar war, dass es ein langer Weg werden würde.

Sven: Und seid ihr diesen Weg bis zum Ende gegangen?

Bernd: Beinahe. Teamscale liefert uns die einzelnen Tests für die Änderungen, aber der Implementierungsaufwand, um in unserer Eclipse-Umgebung einzelne Testmethoden automatisiert auszuführen, war uns am Ende zu hoch. Stattdessen zeigen wir den Entwickler*innen die Tests, die ihre lokalen Änderungen durchlaufen, und die entscheiden dann selbst, welche Tests sie ausführen.

Sven: Ihr habt also die vollständige Automatisierung fallengelassen, weil die letzte Entscheidung der Mensch treffen kann, wenn die Informationen vollständig vorhanden sind?

Bernd: Genau, die Entscheidung kann der Mensch treffen und der bringt ja noch Hintergrundwissen über die Tests und Erfahrung mit. Natürlich weiß man nie genau, was die Kolleg*innen daraus machen. Das merkt man nur, wenn es einmal nicht läuft… (lacht)

Manche Entwickler*innen schauen sich allerdings schon vor ihrer Änderung an, welche Tests durch eine Methode laufen und welche davon unbedingt laufen sollten, um Probleme schon ganz früh zu erkennen. Die große Erleichterung durch die Test-Impact-Analyse ist, aus den 80.000 Tests für zum Beispiel 10 Klassen, oder 10 Methoden, gezielt die relevanten Tests auswählen zu können. Das ist besonders für neue Kolleg*innen, die das Produkt und die Tests noch nicht so lange kennen, sehr hilfreich.

Sven: Welche Rolle hattest du bei der Einführung der Test-Impact-Analyse?

Bernd: Ich war im Pilot-Team, weil meine Kolleg*innen von der Infrastruktur mich für die inhaltliche Betreuung dabei haben wollten. Ich habe das gerne gemacht, weil ich es für sehr hilfreich halte. Mit Teamscale können wir unsere Applikation sinnvoll in einzelne Teile aufspalten, sodass die Entwicklungsteams sehen, was in ihrem Bereich mit der Codequalität passiert und auch in den Tests, das geht an der Stelle ja beides.

Sven: Stimmt, ihr nutzt ja mehr von Teamscale als nur die Test-Impact-Analyse. Was ist denn aus deiner Sicht das Hauptergebnis aus unserer Zusammenarbeit?

Bernd: Ich denke, es ist die Summe. Teamscale überwacht auch unsere Programmierrichtlinien und weist auf funktionale Gefahren hin. Das ergibt ein Sicherheitsnetz, bei dem keine Entwicklung ohne Qualitätsfeedback durchrutscht. Das hilft schon, wenn ich jemanden auf die Defizite hinweise – das ist wie beim Thema Küche aufräumen… (lacht)

Sven: Ihr nutzt also die statischen Code-Analysen und stellt den Entwickler*innen die Tests zur Verfügung. Was war aus deiner Sicht der größte Beitrag der CQSE auf dem Weg dahin?

Bernd: Ich würde sagen, die Testfall-spezifische Coverage, dank der ich sehe, welcher Test wo durchläuft. Das ist der Ringschluss.

Sven: Das ging vor allem in Richtung, was euch Teamscale ermöglicht. Habt ihr das alles alleine aufgesetzt oder auch Beratungsunterstützung durch uns bekommen?

Bernd: Ihr habt euch einmal im Rahmen eines Audits die ASES high-level angesehen und mögliche Risiken identifiziert. Alles andere, die Leute anzusprechen, was wir von den Teams brauchen, und das dann in Teamscale zu konfigurieren, das haben wir selber gemacht. Das war mein Anteil am Projekt.

Sven: Ihr habt dafür also eine Rolle geschaffen, um sich darum zu kümmern?

Bernd: Nicht so ganz… Die anderen haben gesagt: Lass den Bernd mal machen. Und für mich war klar, wenn ich es mache, dann richtig. Wie eine Einführung der ASES beim Kunden: Ich habe geschaut, wohin wir wollen, wen und was wir dafür brauchen. Und man hat mich gelassen.

Sven: Ihr habt also vieles eigenständig gemacht. Heißt das, man kann sich Teamscale einfach nehmen und loslegen, oder ist es sinnvoll, hier mit uns zusammenzuarbeiten?

Bernd: Also ohne die Kollegen der CQSE, die uns betreut haben, wie Raphael Nömmer, hätte ich keine Chance gehabt. Ich weiß aus meinen ASES-Projekten: Wenn ich in einer neuen Software unterwegs bin, ist es essentiell jemanden zu haben, der weiß, wie einzelne Dinge sinnvoll funktionieren und welche Möglichkeiten man hat. Eine Softwareeinführung ohne Hilfe würde ich niemandem empfehlen. Deshalb muss ich das Doing aber ja nicht komplett an einen Implementierungspartner abgeben.

Sven: Vielen Dank. Möchtest du noch etwas hinzufügen?

Bernd: Was ich immer geschätzt habe in der Zusammenarbeit mit allen aus der CQSE ist, dass ihr ein junges Unternehmen seid und dass man euch das anmerkt. Und das ist gut so! Es macht Spaß mit euch zusammen Dinge zu machen und ich fühle mich bei euch gut aufgehoben. Genau das versuchen wir auch mit unseren eigenen Kunden zu erreichen.

Sven: Vielen Dank für das Interview und dieses schöne Schlusswort.