MicroFocus hat zum Embrace Meetup eingeladen. Dieser Event für die Testcommunity war spannend und gespickt mit lehrreichen Präsentationen. Gerne beleuchte ich für euch die Highlights des Tages!

Amir Khan hat den Event zusammen mit Joel Flückiger eröffnet und erzählte über das Thema BDD. Durch die digitale Transformation verschiedener Industrien ist es immer wichtiger geworden eine Software in rasch zu liefern. Time to Market heisst das Schlagwort. Deshalb sind aktuell viele Unternehmen in der agilen Transformation und versuchen die Hürden der immer kürzer werdenden Release-Zyklen zu meistern. Eine Hürde ist die Technik bzw. die Methodik, wie man effizient, qualitativ hochwertige Anforderungen definiert, diese gleichzeitig für jedes betroffene Mitglied im Team (im Projekt) lesbar macht und die Qualitätssicherung realisiert wird, indem diese auch testbar ist. Amir gab uns ein paar „Insights“ dazu.

Risikobasiertes Testing ist trotz agiler Transformation in aller Munde. Trotz des Paradigma-Wandels, ist  eine Realisierung der Qualitätssicherung unabdingbar. Reto Armuzzi zeigte in seinem Speaker-Slot, wie risikobasiertes Testing funktioniert und teilte seine Erfahrungen mit dem Puplikum. Spannend war auch das Rollenspiel, wie eine Situation bezüglich Risikoabdeckung und Risikogewichtung der Testfälle zwischen Projektleiter / Product Owner und Testmanager im Alltag aussieht oder aussehen könnte. Es kamen weitere spannende Präsentationen wie Testautomation mit AI, Value Stream Management und Lasttest-Design einer IDE.

Natürlich, wie bei jedem Embrace-Event, gab es einen Community Track (Team Game). Diese Spiele zeigen beispielsweise auf wie im Alltagstrott einfache Lösungen vergessen gehen. Manchmal hilft es, in stressigen Situationen zurückzulehnen und durchzuatmen – allenfalls eine kurze Pause einlegen – um einen klaren Kopf zu bekommen.

Fotos zum Embrace Meetup können unter folgendem Link abgerufen werden: https://embrace-devops.com/2019/01/29/embrace-meeting-28-01-2019/

Continuous Testing

Ich persönlich durfte das Thema Continuous Testing vorstellen. Ich muss zugeben, dass ich bei der Themenwahl das Gefühl hatte, dass ich mich in diesem Thema auskenne und habe  beim erstellen der ersten Power-Point Slides schnell gemerkt, dass mein Wissen über Continuous Testing sehr lückenhaft ist. Deshalb entwickelte sich meine Präsentationsvorbereitung in einer – schon fast wissenschaftlicher – Recherche. Ich stellte ziemlich schnell fest, dass Continuous Testing von verschiedenen Unternehmen unterschiedlich verstanden wird. Deshalb versuchte ich eine Gegenüberstellung der ausgewählten Unternehmen – und was mir Google vorschlug – zu zeichnen. Das Resultat sah so aus:

Diese Grafik nennt sich übrigens auf Deutsch Wort-Wolke (Word Cloud) und es gibt online viele Tools, die so etwas ermöglichen.

Das Fazit der Zusammenführung:

Jedes der untersuchten Unternehmen interpretiert Continuous Testing aus einer anderen Brille.

Raffaele Russo, Infometis

Ich habe durch diese Analyse kein einheitliches Bild, das in dieselbe Richtung zeigt, bekommen.

Also suchte ich weiter was nun Continuous Testing genau bedeutet und was es ist. Ich stiess auf viele spannende Artikel, die ich gegenüberstellte und für die Präsentation am Embrace Meetup konsolidiert habe und eine klare Aussage zum Thema Continuous Testing bekommen habe.

Während meines Vortrages habe ich das Publikum gefragt, was sie unter Continuous Testing verstehen. Folgende Skizze ist dabei entstanden:

Die Antworten gingen ebenfalls in alle Richtungen, was mich ein bisschen beruhigt hat. Es gibt mehr Menschen da draussen, die kein klares Bild haben, was nun genau dieses Continuous Testing ist.

Die Suche nach einer passenden Definition

Die Definition in Englisch, die ich auf Wikipedia gefunden habe, hat mich nicht losgelassen. Irgendwie hat mich diese Aussage nicht überzeugt. Je mehr ich mich über dieses Thema erkundigte, je skeptischer wurde ich gegenüber der Definition. Es gab Aussagen wie, dass „Continuous Testing mit Continuous Delivery gleichgestellt ist“. Dem ist nicht so. Continuous Testing kann gegebenfalls ein Teil von Continuous Delivery sein. Aber nicht gleichgestellt. Bei Continuous Delivery geht es hauptsächlich darum, dass der entwickelte Code jederzeit deploybar ist. Und wie könnte so etwas möglich gemacht werden? Indem durch eine Kombination von automatisierten und manuellen Tests die Qualität in der Continuous Delivery Pipeline sicherstellt. Dabei versucht man funktionale sowie nicht-funktionale Anforderungen durch unterschiedliche Testtypen zu prüfen. Das war aber nicht mein Thema, aber es ist wichtig den Unterschied zu verstehen.

Schliesslich, konnte ich den Knopf lösen und die Frage, was nun Continuous Testing bedeutet und was es ist beantworten. Die Grafik von Dan Ashby beschreibt Continuous Testing in einem Bild.

Was ist nun Continuous Testing?

Continuous Testing ist eine Art „Software Testing“, das den Testprozess in allen Phasen des DevOps-Infinity-Cycles involviert.

Teste oft, teste frühzeitig, teste überall, teste am richtigen Ort und teste effektiv.

Es handelt sich um eine Strategie, die die Qualität der Software in jeder Phase und zu jedem Zeitpunkt sicherstellt.

Raffaele Russo, Infometis

Oder kurz in einem Satz: Ziel von Continuous Testing ist es früh und oft zu testen.

Ich habe den Bogen weiter gespannt und die Frage gestellt, wie man nun effizient testen kann? Also wie kann ich in immer kürzer werdende Zyklen Testfälle definieren, ohne an Qualitätsverlust zu leiden?

Behaviour Driven Development

Eine Möglichkeit wäre der Einsatz von Behaviour-Driven-Development (BDD). Diese Methodik stammt aus den beiden Techniken Test-Driven-Development (TDD) und Acceptance-Test-Driven-Development (ATDD).

Damit BDD funktioniert, müssen einige Regeln berücksichtigt werden wie:

• Verwende die fünf „Why’s“
• Beschreibe eine einzelne Notation, die für jedes Teammitglied verständlich ist
• Denke von aussen nach innen um den business value zu generieren und waste eliminieren

Durch die spezifische Schreibart von BDD, also das „Given-When-Then“ – oder auf Deutsch „Gegeben-Wenn-Dann“, erwischt man nicht nur zwei Fliegen mit einer Klatsche, sondern man sichert gleich drei wichtige Faktoren:

• Sicherstellung einer funktionalen Dokumentation
• Sicherstellung einer technischen Dokumentation
• Die beschriebene Anforderung ist auch für Teammitglieder ohne technischem Know-How verständlich

Um den Kreis zu schliessen habe ich nach einer Rolle gesucht, die dem aktuellen Trend entspricht. Also sollte diese Rolle ein klares Bild über das Ganze haben und die dafür notwendigen Fähigkeiten besitzen. In der Agilen Welt ist  mir aufgefallen, dass die Autonomie in den verschiedenen Teams ziemlich gut klappt. Was aber meistens fehlt ist eine Gesamtsicht. Schwierig wird es wenn mehrere Teams miteinander zum selben Ziel hin arbeiten (z.B. Scrum in Scrum).

Software Development Engineer in Test

Ich bin auf die Rolle „Software Developent Engineer in Test“ (SDET) gestossen. Diese Rolle erscheint zum ersten mal bei Microsoft. Beschrieben wird diese Rolle als eine Entwickler-Rolle mit erweiterten Skills. SDET soll mit Fähigkeiten ausgestattet sein wie „Collaborative“. Also fähig Teammitglieder mit unterschiedlichen Rollen zusammenzubringen. Also die Tester, die über ein fundiertes Wissen über die Domain haben. Die Entwickler, die den Code kennen und Business Analysten oder Business Owner, die wissen wieso überhaupt eine Anforderung implementiert wird. Durch das näher Bringen dieser Teammitglieder wird ein gemeinsames Verständnis zum gemeinsamen Ziel entwickelt. Eine weitere Fähigkeit ist, dass der SDET stets auf dem neusten Stand der Tools ist. In der sich immer schneller drehenden Welt sollten Testtools der Zeit entsprechen. Ebenfalls die Fähigkeit die richtigen Tests zu automatisieren und nicht blind alles mögliche zu automatisieren. Skills im Bereich Testautomation sind für den SDET ebenfalls wichtig. Diese Fähigkeit sollte helfen waste zu eliminieren. Immer wiederkehrende Tasks können automatisiert werden wie beispielsweise die Erstellung von Testdaten oder das automatisieren von log parsing. Das aufsetzen einer gesamten Umgebung könnte ebenfalls durch Automation effizient sichergestellt werden. Es gibt noch weitere Fähigkeiten, die ein SDET bringen sollte.

Ich bin mir nicht sicher ob dies eine Entwickler Rolle mit erweiterten Fähigkeiten ist. Ich persönlich sehe – stand heute – die Rolle SDET eher beim heutigen Tester bzw. Testmanager. Oder anders ausgedrückt: Könnte das der Testmanager 2.0 sein?
Wir bei der infometis nennen diese Rolle ganz einfach Automation Genius.

Ich bin auf deine Sicht im Kommentarfeld unten gespannt.

Ich persönlich freue mich jetzt schon auf den nächsten Event!