Auch dieses Jahr waren wir als syracom – diesmal in der Besetzung Christoph und Leif – auf dem jährlich stattfindenden German Testing Day in Frankfurt a.M., der firmenunabhängigen Konferenz zum Thema Software-Qualitätssicherung und deren Bedeutung für die gesamte IT-Industrie. Unser Ziel war es, uns Einblicke in die neuesten Entwicklungen und den Stand der „Konkurrenz“ bzw. anderer Firmen in Sachen Test- und Qualitätssicherung zu verschaffen sowie innovative Vorgehen zu identifizieren, die wir ggf. auch bei uns anwenden können. Nachfolgend schildern wir euch ein paar Eindrücke der Vorträge, die wir besucht haben. Viel Spaß beim Lesen!
Los ging es dieses Jahr mit der ersten Keynote von Elisabeth Hocke, die von ihrer Tester-Tour „A Tester’s Journey“ erzählte. Auf ihrer Tour hat sie von Januar bis Oktober 2018 viele verschiedene Personen getroffen (persönlich oder via Konferenzschaltung) um in Sachen Test voneinander zu lernen. Unter anderem hat sie Themen wie Pair Testing, Debugging, Exploration oder auch Pair Automating beleuchtet. Was alle Treffen gemeinsam hatten, war das Testen zu zweit. Ihr erklärtes Ziel war mindestens eine wertvolle Erkenntnis aus jeder Session für sich mitzunehmen, um diese dann später auf ihrem Blog zu teilen. Eine interessante Möglichkeit des Erfahrungsaustausches, die wir bei uns auch unbedingt mal ausprobieren sollten.
Nach der Keynote ging es dann in die verschiedenen Streams – insgesamt gab es 5 Streams mit 28 Vorträgen. Die Themen waren bunt gemischt, von einem kompletten Testautomation-Stack über einen Vortrag zum Requirements Engineering bis hin zu Themen wie Schätzen im Testumfeld war für jeden etwas Interessantes dabei. Die Organisation in Streams brachte allerdings einen kleinen Nachteil: Teilweise fanden interessante Vorträge gleichzeitig statt. Also haben wir uns aufgeteilt, um so viele Vorträge wie möglich besuchen zu können.
In ihrem Beitrag „#NoEstimates - Nie wieder schätzen?“ teilten Anis Ben Hamidene und Amra Avdic ihre Erfahrungen mit dem No-Estimates-Ansatz. Wie der Name bereits verrät, geht es im Kern darum, keine Schätzungen in Form von Abfragen beim Umsetzungsteam vorzunehmen, sondern erfahrungsbasiert auf Grundlage vergangener Entwicklungen vorherzusagen, wieviel umgesetzt werden kann.
Hört sich für mich erstmal nach paradiesischen Zuständen an. Niemand wird mehr dazu genötigt, Schätzungen abgeben zu müssen, man beschränkt sich auf Ableitung und Extrapolation vorhandener Informationen (z.B. bekannte Durchlaufzeit in einem Kanban-Fluss, Anzahl User-Stories je Sprint). Das Geheimnis liegt dann natürlich darin, die Stories immer ungefähr gleich groß zu schneiden – und dies kann eine echte Herausforderung sein. [LG]
Der Stream „From Zero to Test“ von Maik Nogens von der Firma MaibornWolff GmbH beschäftigte sich mit dem Thema Testumgebungen und Testdaten und wie die Kombination dieser beiden Bereiche schnell zu einem Bottleneck für den Test werden können. Je nach Teststufe sind z.B. andere Anforderungen an die Testumgebung und die enthaltenen Testdaten vorhanden. Der hier verfolgte Ansatz von Maik Nogens und seinem Team ist die Ablage ganzer Testumgebungen mit den dafür relevanten Testdaten in sogenannten Docker Containern. Mit Hilfe dieser Docker Container ist jeder Tester jederzeit in der Lage, seine benötigte Testumgebung mit den entsprechenden Testdaten per Knopfdruck zu erstellen und mit der Testdurchführung zu beginnen. Weitere Inhalte, die im Docker-Container fertig eingerichtet sein können: Auswahl der Branches, die deployed sind, oder welche externen Systeme aktiv oder per Mock angeschlossen sind. Der Vorteil eines solchen Ansatzes liegt vor allem in schnelleren Releasezyklen. Auf jeden Fall ein sehr interessanter Ansatz, die Umsetzung ist jedoch meines Erachtens stark vom Kundenumfeld abhängig. [CF]
Im nächsten Vortrag von Erhardt Wunderlich ging es um das Thema Testmetriken. Da auch bei syracom immer wieder heiß diskutiert wird, was denn nun in welchem Kontext die besten Testmetriken sind, erhoffte ich mir hier den einen oder anderen „Hint“. Im Endeffekt war es schwer, hier Ableitungen für uns (mittelständisches Unternehmen mit 200 Mitarbeitern) zu treffen, da es bei dem Beispiel von Herrn Wunderlich um ganz andere Dimensionen ging (Bombardier Transportation, ca. 40.000 MA). So gab es allein 3 Hierarchieebenen bei den Testmanagern (Test Integration Manager, Testmanager, Testkoordinator), von denen jeder seine eigenen Metriken nutzt. Ein Punkt war dann aber doch sehr interessant. Am Ende des Tages interessiert es niemanden, ob 150 oder 180 von 200 Testfällen abgearbeitet wurden, sondern es geht um die Anzahl der fertig (erfolgreich) getesteten Anforderungen. Auch wir sollten uns vielleicht an der ein oder anderen Stelle darauf besinnen, dies wieder mehr in den Fokus unserer Reportings zu stellen. [LG]
Im Vortrag „Die Letzten werden die Ersten sein – Agiles RE und seine Auswirkungen auf das Testen“ von Christian Brandes wurden vor allem zwei Dinge beleuchtet, nämlich wie ein agiles Requirements Engineering konkret aussieht und wie dadurch die Testbarkeit der umzusetzenden Anforderungen sichergestellt oder sogar verbessert werden kann. Das Ziel des RE ist das Erzeugen eines gemeinsamen Verständnisses über das zu entwickelnde Produkt und dessen Nutzer im gesamten Team. Dazu gehört ein gemeinsames Verständnis der Produktvision im ganzen Team. Dazu kann es z.B. gemeinsam ein Produkt-Poster erstellen. Im nächsten Schritt muss das Team verstehen, welchen Aufwand die kommenden User Stories umfassen. Hier beschreibt die User Story nicht jedes für die Entwicklung oder Test nötige Detail, muss aber um die testbaren Akzeptanzkriterien erweitert werden. Danach muss sich das Team die Frage stellen, ob weitere Details dokumentiert werden müssen. Sind z.B. noch weitere Dokumente zwingend für die Story zu erstellen? Diese Dokumente werden dann Teil der „Definition of Done“. Zum Schluss gilt es zu klären, ob es Artefakte gibt (z.B. Entscheidungstabellen, Prozessdiagramme), die dem Team bei der Umsetzung der Story helfen könnten. Beim Identifizieren solcher Artefakte kann ein Artefakt-Poster helfen. Sind solche Artefakte nicht notwendig, genügt die Kommunikation zwischen dem Team und dem Product Owner. Durch dieses Vorgehen entstehen nur Dokumente mit einem echten Mehrwert statt „Schubladen-Doku“. [CF]
Wie schafft man es, neue Kollegen möglichst schnell und effizient zu integrieren? In dieser Session teilte Milan Kuveljic seine Erfahrungen mit Onboarding von QA und Test Engineers bei N26, denn die Herausforderungen sind jedes Mal dieselben: viele Informationen in sehr kurzer Zeit verarbeiten, herausfinden müssen, wie und welches Tool zu installieren ist, wer für welches Produkt verantwortlich ist, versuchen, sich alle Namen zu merken, und so weiter und sofort…
Auf dieser Basis begann Milan einen ständigen Verbesserungsprozess zu initiieren, der sich durch das Feedback neuer Teammitglieder ständig verbessert (KVP). Eine gute Idee, welche syracom in ihren Business Units weiter aufgreifen wird um das Onboarding neuer Mitarbeiter weiter zu verbessern und zu verfeinern. [LG]
Nach der Mittagspause ging es mit dem Vortrag „Leadership Skills – ein Muss für jeden Test Ingenieur“ von Valeriy Burm von der Firma TeamViewer weiter. Hier wurde zunächst der Vergleich zwischen Managern und Leadern in einem Unternehmen differenziert betrachtet. Die These von Valeriy Burm lautete hier: „Leadership used to be what managers do – these days it is what (good) engineers do“. Für ihn haben Manager immer etwas mit Autorität zu tun: Anweisungen von Managern muss Folge geleistet werden, sie haben die Kontrolle über wichtige Entscheidungen. Dem Leader hingegen folgen die Menschen aus eigenem Antrieb heraus, weil sie es selbst wollen. Der Leader inspiriert und unterstützt. Was hat das Ganze nun aber mit Testen zu tun? Zu Beginn seiner Tätigkeit bei TeamViewer war Valeriy Burm selbst Testmanager mit separierten Entwicklungs- und Testteams. In kleinen Schritten hat er diese Hierarchien und die Separierung der Teams aufgelöst. Heute gibt es in seinem Bereich keine Manager mehr. Es sind kleine Teams entstanden, in denen zusammen entwickelt und getestet wird. Die Schlussfolgerung: ein Team braucht keinen Manager, sondern einen Leader. [CF]
Wie viele Änderungen sind ungetestet? Mit dieser Frage beschäftigten sich Andreas Göb und Sven Amann. Im Rahmen einer Live-Vorführung ihres Tools Teamscale zeigten sie anhand visualisierter Codemaps eindrucksvoll auf, wo Code geändert wurde, wo neuer Code hinzukam und ob dieser auch beim letzten Testdurchgang getestet wurde. Denn Codeänderungen sind lt. Amann und Göb ein verlässlicher Indikator für Fehleranfälligkeit. Letztendlich visualisiert die Test-Gap-Analyse Änderungen und Testaktivitäten, um die Produktivsetzung von ungetesteten Änderungen zu verhindern. [LG]
Einen der interessantesten Vorträge hielt Felix Kuperjans von den Testbirds. Er stellte einen vollständigen Selenium Teststack nur mit Open Source Software vor. Vom Testentwurf mit BDD und Cucumber und Zuhilfenahme der Gherkin Syntax über Browser-Testing mit Selenide bis hin zu Continuous Integration mit Jenkins und Jenkins Pipelines sowie anschließendem KI-unterstütztem Reporting wurde hier wirklich alles abgedeckt, was das Testerherz höher schlagen lässt. Der überwiegend theoretische Vortrag schloss mit einer eindrucksvollen Live-Demo des vorgestellten Ansatzes ab – ein echtes Highlight. [CF]
Besonders interessant, vom Ansatz her mutig und letztlich doch nur konsequent, fand ich den Vortrag von Beren Van Daele und Vera Gehlen-Baum. Step by step: jeder kennt das „perfekte“ agile Team. Alles Top-Experten ihres Fachs, jeder benötigte Skill in ausreichender Menge vorhanden. Nicht? Genau vor diesem Problem standen auch Beren und Vera. Viele der benötigten Skills waren im Team nicht vorhanden. Um dies transparent zu machen und den Teammitgliedern auch die Möglichkeit einzuräumen, an ihren Skills zu arbeiten, wurden mit jedem Teammitglied Lernziele vereinbart – von fachlichen Tutorials bis hin zu sprachlichen Fortbildungen. Diese Lernziele wurden neben den offiziell umzusetzenden Tasks auch in das Backlog mit aufgenommen. So wurde nicht nur „nebenbei“ in die persönliche Weiterentwicklung der Teammitglieder investiert, sondern ganz offiziell im Rahmen des Tagesgeschäfts – und zwar mit bis zu 50% der zur Verfügung stehenden Zeit! Einerseits krass und bestimmt auch erstmal schwer zu verkaufen, aber wenn das Team die erforderlichen Skills nicht mitbringt, ist es dann nicht nur konsequent, sondern vor allem auch wichtig und richtig, diesen Zeitaufwand schon beim Sprint Planning mittels eigener Backlogeinträge zu berücksichtigen? [LG]
Zusammenfassend lässt sich sagen, dass sich der Besuch für uns auch dieses Jahr wieder absolut gelohnt hat. Neben der tollen Auswahl waren die Streams auch qualitativ durchweg hochwertig und lieferten uns einen guten Überblick über den aktuellen „Stand der Technik“ über verschiedene Branchen und Themenschwerpunkte hinweg. Auch die Keynotes waren ein absolutes Highlight. Zu guter Letzt sei die hervorragende Organisation erwähnt, an der es nichts zu mäkeln gab. Nichts? Na gut, eine Kleinigkeit gab es dann doch – dass bereits Freitag morgens die tollen Buttons komplett vergriffen waren.
Dieser Blogpost wurde bisher 6369 mal aufgrufen.
Blogpost teilen
Aktuelle Themen frisch aus dem Kopf. Wir freuen uns diese mit Ihnen zu teilen und zu diskutieren.