Hördauer: 30 Minuten
Wie Test Intelligence dazu beitragen kann, das Testen auf Basis der eigenen Daten effektiver und effizienter zu gestalten, erläutert Elmar Jürgens in dieser Folge im Dialog mit Markus und Sebastian. Mit Unterstützung des Werkzeugs Teamscale können Gaps in der Testabdeckung erkannt und die Fehlerfindungsrate von langlaufenden Tests optimiert werden. Wie das bei Kunden ankommt und wie bei der Einführung am Besten vorgegangen werden sollte, kommt im Podcast zur Sprache. Weiterführende Hinweise erleichtern einen tieferen Einstieg in den vielversprechenden Analyseansatz.
Hör' Dir hier den ganzen Podcast an:
Diese Themen erwarten Dich:
[00:33] Kurzer Überblick über den Podcast
[01:13] Vorstellung Elmar Jürgens
[02:25] Was ist Test Intelligence?
[03:13] Steigerung von Effizienz und Effektivität durch Test Intelligence
[04:28] Beispiel für den Nachweis einer Verbesserung anhand gemessener Zahlen
[06:08] Zeitraum für Wirksamwerden der Vorteile
[07:37] Einsetzbarkeit von Test Intelligence
[08:33] Test Intelligence bei automatisierter und manueller Testausführung
[09:27] Teamscale und Test Intelligence: benötigte Daten
[10:48] Visualisierung von Codeänderung
[13:25] Coverage-Analyse in Echtzeit?
[14:33] Welche Programmiersprachen unterstützt Teamscale?
[16:37] Test Intelligence für einzelne Tickets
[17:51] Häufige Ausgangssituationen
[20:19] Relevante Codeänderungen für Tester und andere Rollen
[21:20] Teamscale für Entwickler
[21:58] Rollenübergreifende Nutzung von Teamscale
[22:56] Erste Kunden
[23:31] Kundentreue
[24:46] Branchen wichtiger Kunden
[25:46] Erfolgsfaktoren für die Einführung von Teamscale
[26:52] Hürden bei der Einführung
[27:12] Einsatz bei Startups
[28:07] Aktuelle Heausforderungen
[28:57] Forschung?
[26:52] Kostenlose Workshops von CQSE
Oder lies Dir das ganze Gespräch hier durch:
Herzlich Willkommen, liebe Tester
Community, zu unserer Konversation mit dem Freelance Software
Test Specialist Jonas Rißland heute zum Thema
Testautomatisierung im Versicherungsumfeld.
Vielen Dank für
die Einladung ich freue mich heute gemeinsam mit euch auf spannende Fragen eingehen zu können.
[00:45]
Bevor wir jetzt richtig ins Thema
einsteigen, würde ich Dich bitten ganz kurz zu sagen, was Du heute zum Thema “Testautomatisierung im
Versicherungsumfeld” sagen willst.
In der Versicherungswelt dreht es sich
aktuell oft um Erneuerungsprojekte, neue Frontends (z. B.: Guidwire, BiPro). Mit neuen Entwicklungsprojekten
kommt auch oft die agile Vorgehensweise Scrum oder Kanban und um hier mitzuhalten bietet sich
Testautomatisierung einfach an. Darüber würde ich gerne mit euch sprechen.
[01:58]
Bevor wir ins Thema tiefer
reingehen, wäre es schön, wenn Du noch kurz ein paar Worte zu Dir sagen könntest... Wer bist Du und was hast Du für Schwerpunkte?
Sehr Gerne. Ich bin seit 7 Jahren als
Tester, Testautomatisierer und Testmanager bei unterschiedlichen Firmen tätig gewesen und in
unterschiedlichen Projekten. Seit letztem Oktober bin ich selbstständig tätig. Gelernt habe ich
Fachinformatiker für Anwendungsentwicklung und war auch gute 2 Jahre als Entwickler tätig bevor es mich
wieder zurück zum Testen gebracht hat, was ich während meiner Ausbildung schon kennengelernt hatte. Privat Tüftel ich gerne mit Arduinos und Raspberry Pis rum und
praktiziere Elektrotechnik.
Einsatzumfeld
[03:06]
Du hast
bist vor kurzem in einem größeren Projekt in einer Versicherung als Testautomatisierer gearbeitet.
Siehst Du Besonderheiten im Einsatzumfeld Versicherungen ?
Der Wandel der Zeit. Aktuell müssen viele
große Versicherungen mit kleinen neuen schnellwachsenden Konkurrenten mithalten, die meist sehr digital und
Transparent sind um darauf reagieren können, was der Kunde wünscht. Dies führt zur Etablierung von Agilität
und jüngerer Denkweisen.
[03:53]
Wieviel
Testautomatisierer gab es im Projekt ?
Wir waren am Ende zu 3. und betreuten
öfter einen Auszubildenden.
[04:07]
Warst Du
der erste Testautomatisierer im Projekt ?
Nein, ich kam als zweiter interner
Testautomatisierer in das Projekt.
[04:33]
Wie war
die Situation der Testautomatisierer im Projekt als Du dazu gekommen bist?
Als ich zu dem Projekt kam gab es einen
internen und 3 externe Testautomatisierer. Die Qualität der zu automatisierenden Testfälle setze viel
fachliches KnowHow und Knowledge der Software voraus. Es war recht unorganisiert und wir mussten oft
Testfälle von den fachlichen BAs verbessern lassen, welche auch die Testfälle schrieben.
[05:38]
Wie
haben sich die Teamstrukturen bei den Testautomatisierern im Projekt über die Zeit geändert
?
Nach kurzer Zeit im Projekt fielen die
externen Kollegen komplett weg und wir bemühten uns um einen weiteren internen Kollegen, der zeitnah
gefunden wurde und uns sehr gut durch sein Testautomatisierungs-Know-How unterstützen konnte. Zusätzlich
wurde oft die Struktur verändert. Um uns als Team zu orientieren versuchte ich SCRUM zu etablieren, nach
kurzer Zeit schwenkten wir jedoch auf Kanban, womit wir besser die Tätigkeiten abarbeiten konnten und
deutlich spontaner auf Releases oder Hotfixes und die dazugehörigen Tests reagieren konnten.
Letzten Endes wurde beschlossen die
Testautomatisierer aufzuteilen und den einzelnen Entwicklungsteams im Projekt zuzuordnen, zusätzlich dazu
wurde eine Testautomatisierung-Gilde etabliert zum Austausch über Weiterentwicklungen des Framworks. Leider
habe ich die letzte Phase nicht mehr voll mitbekommen.
[07:11]
Wie war
die Zusammenarbeit mit Testautomatisierern aus anderen Teams ?
Wie leider sehr oft der Fall benötigt es
für die Zusammenarbeit Motivation, diese war nicht wirklich vorhanden bevor ich dazu kam. Gemeinsam mit den
zwei Kollegen führten wir Austausch mit Kollegen des Mutterkonzerns und auch intern gelang es mir einige
Gespräche mit anderen Projekten die Testautomatisierung betrieben zu führen.
[08:41]
Welche
organisatorische Aufstellung von Testautomatisierern hälst Du für die Beste ? Ein Team von
Testautomatisierern oder die Mitarbeit von Testautomatisierern in fachlich dominierten Teams
?
Das würde ich von der Struktur des
Projektes abhängig machen. Wenn es beispielsweise 4 oder 5 Entwicklungsteams in dem Projekt gibt aber nur 3
Testautomatisierer, dann ist es sinnvoll mit dem Testautomatisierern gemeinsam ein Konzept der Arbeitsweise
auszuarbeiten. Wenn die -Anzahl der Teams zur Anzahl der Testautomatisierer übereinstimmend ist, macht es
Sinn diese direkt einem Team zuzuordnen. Jedoch sollten die TAs Zeit eingeräumt bekomme damit mögliche
Punkte zur Überarbeitung oder Erweiterung des Testframeworks nicht zu kurz kommen.
[09:35]
Hat sich
die Testautomatisierung im Projekt auf die Automatisierung von Oberflächenaufgaben beschränkt
?
Die Automatisierung war sehr stark auf die
Oberflächen-Testautomatisierung beschränkt. Jedoch zum Test von BiPro wurde SOAP-UI und für Lasttests (durch
externe Dienstleister) Neoload verwendet.
Testprozess
[10:07]
Spielte
die Testautomatisierung in der Teststrategie eine Rolle ?
Ja es wurde ein hoher Grad an
Testautomatisierung in der Teststrategie erwähnt, jedoch wurde dieser leider nicht erzielt.
[10:33]
Gab es
da technische Ursachen oder andere ?
Ich denke, es lag mit am Aufbau des
Projekts. Letztlich braucht man eine Nachvollziehbarkeit von Features zu Tests also zur Testabdeckung. Wenn
die Connection nicht vorhanden ist, gibt es halt diesen Punkt, dass es nicht funktioniert.
[10:53]
Wie
schwierig war es, Testanalysten zur Erstellung geeigneter Testfallvorlagen zu bewegen ?
Erstmal vorweg, wir hatten leider keine
Testanalysten sondern nur Business Analysten. Diese mussten neben der Erstellung neuer Tasks und deren
Betreuung in der Umsetzung noch die Testfälle erstellen, da die Prio auf der Entwicklung lag, bedurfte es
mehrere Anläufe bevor wir neue Testfälle erhielten, dies zog sich teilweise über Wochen hinweg.
[11:55]
Wie seid
Ihr vorgegangen, um die benötigten Testfallvorlagen von den Testanalysten zu erhalten ?
Damit wir die Atomarität der Testfälle
erhöht werden konnten, haben wir entschieden Termine mit den BAs zu machen und sie zum einen abzuholen, was
TA ist und wie Testfälle beschrieben sein sollten. Zusätzlich haben wir mehrere Termine angesetzt pro
Entwicklungsteam um gemeinsam neue Testfälle zu besprechen oder eine Vorgehensweise für die Unterstützung
unserer Seite zu definieren.
[12:54]
Wie habt
Ihr von Änderungen an bereits implementierten Testfallvorlagen mitbekommen ?
Meist durch auftretende Fehler beim
ausführen der Testfälle. Je nach Team kamen die Infos aber teilweise auch vorher. Zusätzlich durch eigene
Recherchen in den einzelnen Scrum-Boards der Teams. Die Situation sollte sich durch das Aufteilen in die
einzelnen Entwicklungsteams etwas verbessert haben, so zumindest die Theorie.
[14:05]
Wie
sollte die Kommunikation von solchen Änderungen Deiner Meinung nach am Besten laufen ?
Je nach Aufstellung. Aber wenn das Tool
gescheit genutzt wird und die Testfälle zu User Stories oder Epics verknüpft sind sollten diese bei
Änderungen an der Funktionalität zum Review markiert werden und die fachlichen Tester sollten dies dann auch
umsetzen (Wunschdenken). Ich denke so ein Szenario ist nur schwer umsetzbar, aber Infos an die
Testautomatisierer zu geben wäre in vielen Punkten von Vorteil, jedoch müssten dann alle BAs wissen, was
fachlich in ihrem Bereich betroffen sein könnte.
[15:02]
Hälst Du
es für sinnvoll, Teammitglieder ohne Automatisierungserfahrung aktiver in die Testautomatisierung
einzubeziehen ?
Das kommt immer auch auf den Typ Mensch
an. Ich denke wenn das Team gemeinsam etwas bewirken will, ist es simpler einen solchen Weg einzuschlagen.
Generell sollten die Personen aber mindestens wissen was TA bedeutet und was alles dafür benötigt
wird.
[15:53]
Was
hälst Du von BDD, insbesondere von Cucumber ?
Da bin ich zwiegespalten. Aus meiner
Brille als aktuell Testmanager finde ich es spannend, da so vieles eventuell schon deutlich früher gescheit
ausformuliert werden müsste und man sich so ggfs. durch die Normung der Anforderungen schon Testfälle
schreibt und gar nicht erst eigene Testfälle definieren muss.
Auf der anderen Seite sehe ich, dass es
immer einen guten Grund für seperatisierte Tester gibt, die die Software basierend auf den Anforderungen
tests. Hierbei gilt, dass ein Tester nicht nur das testen wird, was in der Anforderung steckt, sondern noch
über den Tellerrand hinaus denkt. So kenne ich das zumindest von mir. Die Anforderung ist eben nicht
gleichzusetzen mit den Testfällen.
[17:01]
Wo
siehst Du Schwierigkeiten bei der Einführung eines Vorgehens wie BDD/Cucumber ?
Die Norm-Sprache muss etabliert werden,
jeder muss es wollen. Die Keywords müssen klar definiert werden und der Code hinter einem solchen Keyword
muss ebenfalls definiert
[17:34]
Behaviour Driven Testing ist ja meistens eher bei den Testautomatisierern
beliebt. Wie überzeuge ich den fachlichen Bereich das zu nutzen ?
Das bedarf viel Pflege der Beziehungen.
Man muss sich mit denen zusammensetzen, die Vorteile zeigen, z.B. in Form von Workshops.
Testdatengenerierung
[18:08]
Ihr habt
generierte Testdaten in Euren automatisierten Skripts verwendet. Warum kann es sinnvoll sein, Testdaten
für automatisierte Tests auf Vorrat zu produzieren ?
Klarer Vorteil ist, dass die Testdaten
bereits im Testsystem vorhanden sind. Man mach sich zeitlich unabhängig von der Ausführung. Wenn für die
Testdatengenerierung ebenfalls die Oberfläche Benutzt werden muss, da es keine API oder DB-Zugriffe gibt,
dann kann dies ggfs. pro Testdatensatz bis zu mehreren Minuten in Anspruch nehmen.
Zusätzlich dazu wird die Ausführung der
Tests deutlich entkoppelt von der Funktionalität die für die Testdatengenerierung benötigt wird. Wenn diese
defekt wäre, würde zwar ein Fehler im System eingetragen, der noch behoben werden kann vor dem Live-Gang
aber die restliche Funktionalität könnte noch durchgetestet werden und so kann die Qualität der Software
insgesamt besser bewertet werden.
Großer Vorteil, wenn man es tagsüber nur
selber machen kann, blockiert es die Hardware von einem selbst. So ist es, dass es auf einer virutellen
Maschine, meistens auf einem Server läuft und nachts ausgeführt wird. Tagsüber kann man dieselbe Ressource
zum Ausführen von Testfällen verwenden.
Technologien und Frameworks
[20:18]
Welche
Technologien habt Ihr für die Testautomatisierung eingesetzt ?
Ein eigenentwickeltes Testframework
,welches auf Selenium in Java basierte.
Es hatte unterschiedliche Clients zum
anbinden von Host-Software via Telnet oder auch zum Anbinden von Jira zum auslesen der einzelnen Testpläne,
welche mit dem AddOn TestFlow erstellt wurden. Wir haben dafür das Jira-Addin Testflo verwendet.
[21:06]
Das von
Euch verwendete Test Automation Framework war ein “Eingenprodukt” der Versicherung. Wie hast Du es zu
Beginn in Deinem Projekt vorgefunden und wie hat es sich weiterentwickelt ?
Das Produkt war sehr aufgebläht, den
Zustand konnten wir mit der Zeit und durch Anwendung von CleanCode, dies war eine Anforderung des Projektes,
nach und nach etwas verschlanken und besser verständlich machen. Teilweise wurden Erweiterungen für die
Integration von Schnittstellen eingebaut.
[21:54]
Mit der
Eigenentwicklung kam ja dann auch Softwareentwicklung ins Projekt. Hat das die Komplexität der Projekts
erhöht ?
Die Testautomatisier, die wir im Projekt,
hatten waren alles Softwareentwickler. Letzten Endes war eine höhere Komplexität vorhanden. Letzten Endes
aber auch nein. Wir haben das Projekt vom Mutterkonzern übernommen und angepasst. Jedes
Testautomatisierungsframework hat den Aspekt, dass man Entwicklung schon kennen und auch damit umgehen
können sollte.
[22:35]
Ihr habt
ein organsationsinternes Testframework verwendet. Hättest Du die Verwendung eines verbreiteten
Testframeworks besser gefunden ?
Generell denke ich jeder benutzt ein
Framework und passt es an seine Bedingungen an. Bei uns war es eben Selenium mit einem sehr groß
aufgebauschtem eigenen Framework.
Aus mehreren Gesichtpunkten ist es
sinnvoll nicht zu weit von Standards abzuweichen. Der größte Punkt dabei ist, finden von neuen Mitarbeitern,
bei dem verwendeten Framework benötigt es mindestens 3-6 Monate der Einarbeitung. Sollte der Standard oder
ein etablierteres Framework verwendete werden, sollte das deutlich schneller gehen. Natürlich benötigt es
dennoch immer eine gewisse Einarbeitungszeit.
[23:41]
Ihr habt
Euch andere Frameworks angeschaut, z.B. das Robotframework oder das Testautomation Framework der Firma
Qytera. Was waren letztlich die Beweggründe beim organisationsinternen Framework zu bleiben
?
Der Hauptgrund für die Entscheidung war
der Projektfortschritt. Hätten wir ein neues Testframework einsetzten wollen, so hätten alle bereits
bestehenden Testfälle auf das neue Framework angepasst werden müssen. Die Pflege von zwei Frameworks wäre
unsinnig und der Umzug bedeutete Aufwand von vermutlich mehreren Monaten, in dieser Zeit würde ebenfalls
keine neuen Testfälle umgesetzt werden, da das Personal nicht erhöht werden konnte.
Integration in die CI-/CD Pipeline
[24:34]
Wie
erfolgte die Integration der automatisierten Tests in die CI/CD-Pipeline ?
Learning by doing war hier das Motto, ich
hatte den Wunsch uns mehr Zeit für die Automatisierung zu verschaffen und somit war es für mich ein
logischer Schritt das die Ausführung der Testfälle in Jenkins erfolgen sollte und mindestens die Smoketests
direkt nach einem erfolgreichen Deployment getriggert werden könnten.
Wir haben gemeinsam mit einem Kollegen der
die Entwickler Pipelines betreute ein Konzept erarbeitet. Die Pipeline zur Ausführung habe die TAs
geschrieben, dies war in den ersten 6 Monaten großteils meine Aufgabe. Die anderen Kollegen konnten sich
daher mehr auf die Umsetzung der Testfälle fokussieren.
Der Aufruf der Testing Pipeline wurde dann
direkt vom Kollegen in die Deploymentpipeline integriert.
[25:51]
Warum
ist es besser, Regressionstests manuell anzustarten ?
Die Frage ist jetzt eher zum kontern
geeignet. Ist es wirklich besser Regressionstests manuell zu starten? Ich denke generell ist es sinnvoll
auch Regressionstests in eine CI/CD Pipeline mit einzubinden und diese nach erfolgreichen Smoketests
auszuführen. Jedoch wurde die Anbindungen an den CI/CD Prozess erst während meiner Zeit für die Smoketests
umgesetzt und die Anbindung der Regtests wurden geplant aber bis dato nicht umgesetzt.
[26:48]
Hatte
das eventuell mit den Laufzeiten der Regressionstests zu tun ?
Ja, das stimmt. Wenn man darüber
nachdenkt, was man damit erreichen will. Die Auswertung der Ergebnisse der Regressionstests können auch
später ausgewertet werden. In jedem Fall sollten die Smoketests erfolgreich durchgelaufen sein bevor die
Regressionstests gestartet werden.
[27:38]
Was hat
Euch bewogen die Testdatengenerierung in die CI/CD-Pipeline zu verlegen und welche Besonderheiten sind
dabei zu berücksichtigen ?
Wir hatten sehr hohe Aufwände für die
Erzeugung der Testdaten ohne Automatisierung und zusätzlich lokal. Dies bedeutet es konnten keine weiteren
Testfälle entwickelt werden in der Zeit. Es fehlte Zeit für die Umsetzung in CI/CD, daher hatte jeder TA für
sich selbst eine schnelle automatisierte / oder Teilautomatisierte Lösung mit bash erstellt. Die Skripte
konnten teilweise ohne große Änderungen direkt in die CI/CD Pipeline in Jenkins übernommen werden, aber zum
besseren Ausführen wurde ein komplettes Konzept erzeugt, welches letztlich nach meinem Ausscheiden in groovy
umgesetzt wurde.
So sollten sollten die Skripte nicht mehr
lokal sondern auf den Jenkins-Nodes ausgeführt werden und wie im Konzept mit eingeplant keinerlei Aufwände
mehr für die TAs anfallen, da die Testfälle automatisch mit neuen Testdaten in einem Nightly Build je nach
Bedarf aufgefüllt werden.
Nutzung einer Vault für die Berechtigungen der Testautomatisierungsuser
[29:51]
Für die
automatisierten Testfälle sind Nutzer mit verschiedenen Berechtigungsprofilen notwendig. Welche
Änderungen haben sich zuletzt bei Verwendung dieser User ergeben ?
Es gab mehrere Sicherheitskritische
Vorfälle, daher wurde der Beschluss gefasst alle Benutzerdaten, auch von Testsystemen komplett in Vaults
auszulagern. Vorerst gab es eine schnelle Lösung wo die Nutzer verschlüsselt abgelegt wurden und kurz vor
meinem Abschied konnten wir sogar eine eigene Vault erhalten. Die Anbindung in Java sollte dank vorhandener
Plugins schnell erfolgen. Das wurde mir auch von einem ehemaligen Kollegen bei unserem letzten Gespräch
bestätig.
BIPRO
[30:55]
Der
Schwerpunkt Eurer Tätigkeit war Frontend-Testautomatisierung. Ihr hattet aber auch mit Tests des
Service-APIs für Versicherungen - BiPro - zu tun. Was war Eure Aufgabe ?
Es gab bereits extern entwickelte Tests in
einem vermutlich eigens entwickelten Framework, welches mit Excel-Dateien arbeitet und die API-Requests
abschickte.
Die Ausführung und Auswertung wurde von
unserem Team betreut.
Zusätzlich unterstütze ich ein
Entwicklungsteam bei der Einführung einer Jenkins-Pipeline um von Ihnen entworfene Schnittstellen-Tests in
SOAP-UI auszuführen.
[31:57]
Hälst Du
es für sinnvoll, in einem Framework die Testautomatisierung von Front-End und API unterzubringen oder
sollte man das eher getrennt halten ?
Den Vorschlag hatte ich schon einmal
gebracht, generell hätte es die Möglichkeit gegeben es mit in dem eigenen Automatisierungsframework
[32:37]
Es ist
am Ende einfacher daraus zwei verschiedene Projekte zu machen oder nur ein einziges ?
Vorteil eines Standardframeworks ist
es
[33:11]
Details
zum im Projekt eingesetzten Framework für automatisierte BiPro-Test
Ja es wurde ein extern entwickeltes
Framework eingesetzt, was spontan in die Hoheit der Testautomatisierung überging. Vorher war es in der
Hoheit der Fachlichen Teams. Daher konnten wir nur eine Betreuung anbieten. Des weiteren wurde SOAP-UI
eingesetzt. Dies wurde von einem Entwicklungsteam genutzt und gemeinsam mit TA wurde die Ausführung in einer
Jenkins-Pipeline etabliert.
[33:55]
Du hast
Dich vor kurzem selbständig gemacht. Wie können Interessierte mit Dir Kontakt aufnehmen
?
Aktuell bin ich bis Ende März in einem
Projekt, aber sehr gerne nehme ich den kleinen Werbeslot an. Ich bin via Linked-In, Xing oder per Mail
erreichbar unter: jonas.rissland@outlook.de.
Gerne wenn auch gerade nicht für ein
Projekt verfügbar, können wir auch einfach nur für einen Austausch zusammenkommen.
[34:44]
Was
hälst Du persönlich von ISQTB-Schulungen? Würdest Du den Besuch des ISTQB-Seminars Test Automation
Engineer empfehlen ?
Persönlich bin ich im Advanced Bereich zum
Testmanager zertifiziert. Das ISTQB-Seminiar zum Test Automation Engineer steht noch auf meine ToDo-List.
Wenn es so wird wie meine letzten Schulungen in dem Bereich, dann werde ich mein bisheriges Wissen stärken
und weiter Punkte mitnehmen können, die mich zukünftig weiter bringen.
[35:52]
Vielen Dank Jonas, dass Du Dir Zeit
genommen hast, uns Einblicke in das Thema Testautomatisierung im Versicherungsumfeld zu geben.
(Grußworte
von Jonas …)
Sehr gerne es freut mich heute Teil eures
Podcasts sein zu dürfen und gerne komme ich noch einmal mit in eine Runde. Allen Zuhörern wünsche alles Gute
und vielleicht schreibt oder hört man sich in Zukunft in diversen Socialen Medien.
Wenn aus der Tester-Community noch jemand
Anregungen hat, Feedback geben will, dann schreib bitte an podcast@qytera.de.
Vielen Dank fürs Zuhören und bis zum
nächsten Mal.
08. März 202309. März 2023Finden Sie weitere interessante Artikel zum Thema:
Artikel weiterempfehlen: