Agile Testing Days 2021 meine Highlights 2. Konferenztag

For my non-German-speaking quality colleagues: Please use deepl.com Thx!

Der erste Tag war nicht durch den zweiten zu toppen, auch weil ich abreisen musste, aber schön war es dennoch, denn es ist die Idee zwischen Nathalie, Björn (Evertest, Belgien) und mir entstanden, in einer belgisch-deutschen Koperation eine Session für die kommenden Agile Testing Days zu bauen, da uns der Aspekt „Wie kann man Ideen testen?“ doch mal näher beleuchtet werden sollte.

Am zweiten Tag bin ich, anstatt zu laufen, bei Janet mit am Lean Coffee-Tisch gelandet. Die Probleme sind oftmals dieselben, aber leider sind die Firmen nicht dieselben: Wie bekommt man die Verantwortung für Qualität in die Köpfe aller im Team.

Even though I was late due to the covid test and registration, I learned something during the lean coffee this morning. Thanks #AgileTD pic.twitter.com/AW8TFi33bi
— Bart The Tester (@bartthetester) November 17, 2021

Jutta hat es sehr schön aufgezeigt: Soziale, ökonomische und eben auch die bekannten Umgebungsaspekte zusammen ergeben Nachhaltigkeit.

Now the story of how Chef developers rebelled against the contract with ICE and that had a real impact – it will not be renewed. Shows us that people have more power than they think and we must all be responsible for our part towards sustainability. @JuttaEckstein #AgileTD pic.twitter.com/eNK5A10WiA
— João Proença (@jrosaproenca) November 17, 2021

Ich fand es beeindruckend, dass die Entwickler.innen von CHEF damit gedroht hatten, den Code auszubauen, den die Heimatschutzbehörde der USA leider völlig losgelöst von den Werten der erschaffenden Menschen eingestzt hat. Anderes Beispiel, das Jutta nicht genannt hatte: Die Story im Sommer 2018 von Google und dem „Maven-Projekt“ hatte zur Folge, dass nun Jeff Bezos und die Microsofties das Drohnenprojekt betreuen, aber eben nicht Google. Da haben sich Mitarbeiter.innen auch mal dagegen gewehrt an so einem Mist mitwirken zu müssen und zumindest meinen Respekt eingeheimst.

Crowd Testing – eine andere Welt

Ich persönlich bin selbst auch in einer „crowded Tester-Community“, aber ich wusste gar nicht wie konzentriert der Markt auf ein paar globale Player zusammen[gekauft|geschrumpft] wurde. Ich war bei einem Vortrag, der spärlich besucht war, um mich mal auf den neuesten Stand bringen zu lassen. Mitlerweile sind die Plattform-Anbeiter (gerade was die mobilen Devices angeht) verbandelt mit den TaaS-Anbietern, aber ansonsten ist m.E. da alles wie man es sich für einen END-Abnahmetest das so vorstellt.

Quality Dojo

„What’s a quality dojo“ by @zfordreitz is about to start #AgileTD pic.twitter.com/C0MrZmVYrj
— Tobias Geyer (@the_qa_guy) November 17, 2021

Zed hat die Regeln, die bei ihm angewendet werden schön erklärt, sodass ich auch an unser Team noch was übermitteln kann, was wir ggf. auch mal in Betracht ziehen könnten. „Hopp-on-hopp-off ohne erklären zu müssen warum“ fand‘ ich schon mal inspirierend. Schön, dass nun immer mehr Firmen das Training auch als Bestandteil der Arbeit ansehen. Nur durch ständiges Training wird man eben besser.

Risk Storming

Risk storming with @TestSphere by @isleoftesting described by @jrosaproenca #AgileTD pic.twitter.com/fN8MdJIPrs
— Göran Kero (@ghkero) November 17, 2021

João Proença hat dafür schon die Nominierung fürs kommende Jahr (bei mir persönlich) gewonnen, denn auch ich trainiere gerne Risk Storming, weil es eines der effizientesten Methoden ist, dem Team die wichtigsten Risiken bewusst zu machen. Die ganze Keynote „Limitless with our Boundaries“ war toll, denn es ist gut eine Auswahl zu haben, aber die Anwender.innen oder Entwickler.innen immer vor einer schier unendlichen Auswahl von Möglichkeiten zu stellen, ist, wie er eindrucksvoll dargstellt hat, nicht immer die beste Idee.

Der Tag 2 war kürzer wegen der Bahnfahrt, aber es waren zwei sehr lehrreiche Tage und anscheinend hatten auch die anderen Unicorns ihren Spaß.

Agile Testing Days 2021 meine Highlights 1. Konferenztag

For my non-German-speaking quality colleagues: Please use deepl.com Thx!

Die meinesten meiner Test-Kolleg.innen schreiben in Englisch. Meine Gedanken sind aber generell in meiner mir angeborenen Sprache und daher vermeide ich es meine Gedanken durch Übersetzungsleistung zu zerstören. Dafür gibt es Maschinen.

Ich war dieses Jahr, nach 2019 mit dem ganzen Team, zwei Tage auf den Agile Testing Days und habe mich daher fokussiert, aber leider auch vieles nicht mitbekommen – dazu ist das einfach zu viel Input und zu groß. Schön wäre es kommendes Jahr wieder mit mehreren des Teams dort aufzuschlagen, damit nicht so viel verloren geht.

🏃‍♀️🏃 Our attendees are ready for the first morning run at #AgileTD!
Are you an early bird or a night owl? 🤔 pic.twitter.com/Gyi84pOKoB
— Agile Testing Days (@AgileTD) November 16, 2021
Twitter

Begonnen hat der Tag mit einer sportlichen Herausforderung, die sehr viel Spaß gemacht hat. Die Treppen von Sans Souci sind morgens um 7 schon eine Herausforderung 🙂

#AgileTD morning run number one through the Sans Souci Park done 🏃
Helped a lot to shake of the after effects of the speaker dinner 😅 pic.twitter.com/bIJYnysEua
— Michael Kutz (@MichaKutz) November 16, 2021
Twitter

Die erste Keynote von Prof. Dr. Dagmar Monett von der Humboldt Uni in Berlin hatte es gleich mal voll drin: Rumschlagen mit Definitionen, denn es ging um das Thema „intelligente“ Maschinen.

Liebe IT-Manager.innen, hier steht es von jemanden, der es wissen sollte (danke an Oana für den Tweet):

We have powerful fast calculating machines, but how can we say they can be intelligent as we have actually a hard time to define what intelligence is. Tx @dmonett to state This ! Hallelujah! #agiletd @AgileTD pic.twitter.com/LL6ukExC9j
— Oana Juncu (@ojuncu) November 16, 2021
Twitter

Schon in den 90ern, als wir mit BBS-Systemen rumgespielt haben, versuchte man uns glaubhaft zu machen, dass es so etwas gäbe, aber es gab es nicht! Die Rechner und die Software sind nur besser geworden. Das ist erst einmal so und ja, es gibt tolle Modelle, die mit extremer Leistung Sachen vorhersagen, ableiten, berechnen können, aber „Intelligenz“ ist das dann mal mitnichten. Die Gute hat auch mal mit der Herkunft solcher Mythen aufgeräumt, denn die Medien mit ihren Star Wars und anderer Sciene Fiction prägen das was wir unter „intelligenten Maschinen“ sehen. Das ist es nicht.

Fantastic Biases and where to find them in software development!!#AgileTD @MichaKutz @jrosaproenca some #emnanotes again pic.twitter.com/lCSfbvjkw9
— Emna Ayadi (@emna__ayadi) November 16, 2021
Twitter

Was Kollegin Emna, die ich auch persönlich beim Mittag kennenlernen durfte, in ihrer schönen Sketchnote aufgeschrieben hat, hat mich wieder fasziniert, da man immer wieder auf Vorturteile und auch Annahme reinfällt, obwohl man es eigentlich besser wissen sollte…

u.a. bin ich selbst auf die Annahme hereingefallen, dass die vorherrschende Meinung von Qualitätsverantwortung in agilen Teams bekannt sein sollte. Das dem nicht so ist, haben wir bitter erfahren müssen. Wir versuchen nun nachzusteuern um den Effekt entgegenzuwirken, dass [von oben] angenommen werden könnte, jede.r hat dasselbe Verständnis über Qualität und Testen in agilen Teams in der gesamten Organisation. Dafür ist es gut, dass wir ein sehr diverses Team aus unterschiedlichen Rollen und Charaktere sind – so werden Annahmen wenigstens hinterfragt und jemand aus unserem Team „ermahnt“ uns auch immer, alles zu visualisieren, damit wir wirklich vom Selben reden.

Damit aber nicht genug, auch das Anwerben neuer Mitarbeiter.innen hat bei uns Priorität, nachdem wir sehr früh feststellten, dass in der agilen Transition die Qualitätsbewahrer.innen abhanden gekommen sind. Die Personalabteilung scheint alles in Normen und Rollen verankern zu wollen, aber die Diversität und die Andersartigkeit von Menschen in denselben Rollen schafft es, dass man in die Ecken schaut, wo sonst nicht hingeschaut werden würde.

Sehr hilfreiche Tipps von Micha und João (Präsentation) und das wird mich garantiert noch weiter beschäftigen… wie man oben sehen konnte, nicht nur in den Räumen, wo sie gesucht und gefunden haben 🙂

#agiletd
Exploratory Testing in regulated environment.@mariapetzold13 and @Flo_Pilz pic.twitter.com/2Y9wVpU7Ik
— MaikNog (@MaikNog) November 16, 2021
Twitter

Eine sehr praktische Sicht kam dann am Ende des ersten Tages, da unter regulatorisch Umgebungen, nicht nur meiner Meinung nach, explorativ getestet werden kann und sollte, denn Maria Petzold und Florian Pilz von ZEISS haben mal vorgestellt, wie sie das so machen. U.a. geben sie auch das Vorgehen und die Hilfsmittel einfach mal so raus, was ich sehr löblich finde.

Ways to counter toxic leadership @epsilon11 #agileTD pic.twitter.com/8XTqDrEozQ
— lisacrispin (@lisacrispin) November 16, 2021
Twitter

Feed-back to a manager. Met this type of manager, anyone ;)? #AgileTD @AgileTD pic.twitter.com/GuAcjJjqpS
— Oana Juncu (@ojuncu) November 16, 2021
Twitter

Unser späterer MIATPP-Gewinner (Most Influential Agile Testing Professional Person) Raj Subrameyer hatte schon vor ein paar Jahren auf den AGT etwas zu seinem Weg raus aus dem Unwohlsein berichtet und nun noch einmal etwas tiefergelegt. Toxische Leader gehen leider nie in diese Keynotes, denn das was man da rausziehen könnte, wären Spiegel, die dann die Wahrheit mal sehr offensichtlich machen.

Man kann diese toxischen Umgebungen brechen, aber dazu müssen die Leader auch bereit sein. Manchmal wird man auch nach Jahren noch negativ überrascht und daher galt und gilt für mich immer das Leitmotto:

Tue das was Du liebst!

[Viel] Geld wird Dir das nicht ersetzen können. Ich gehe nicht für jemanden arbeiten, sondern ich gehe meiner Tätigkeit mit Leidenschaft nach und da kann der Arbeitgeber auch mal wechseln, auch wenn ich gerne länger bei Unternehmen meiner Leidenschaft nachgehe, da Qualität aus dem Inneren des Unternehmens erwachsen muss. Raj hat seine Leidenschaft gefunden und er macht nun das was er liebt.

Inbox Zero – Zweite Woche

Nun läuft privat auch die zweite Woche mit 0 Mails in der Inbox und….

Es funktioniert

Es klappt in der Firma mit dem „Gruppenpostfach“ schon seit Monaten und in der zweiten Woche auch privat.

Ich bin entspannter. Einige Mailinglisten haben nun einen Empfänger weniger, aber gelesen hatte ich das Zeug nicht wirklich.

Fokus

Der Fokus ist nun auf die wenigen Mails und die kann ich, gemäß meinen Grundsätzen, sehr zeitnah abarbeiten und übersehe weniger.

Inbox Zero Startposition erreicht – strukturierte E-Mail-Kommunikation ist keine neue Erfindung

Um die Übersicht der täglichen Arbeit zu gewährleisten und das Wichtigste nicht aus den Augen zu verlieren, empfiehlt es sich bei dem leidigen Kommunikationsmedium Nummer 1, der E-Mail, eine gewisse Struktur zu wahren.

Der „Inbox Zero“-Kult ist bei mir zu Z-NETZ-Zeiten entstanden, da als Sysop und späterer FIDO-Net Hub-Administrator sich User und Sysop-Kollegen auf die korrekte Abarbeitung ihrer Anfragen verlassen mussten.

Gruppenpostfach muss sauber bleiben

Es ist total wichtig gemeinsame Postfächer, sog. Gruppenpostfächer (Outlook-Slang), aufgeräumt zu halten, da sonst Aufgaben durchrutschen werden.

Wir machen es so,

dass jede/r sich in ihrem/seinem lokalen Outlook eine Farbe einer Kategorie ausgesucht hat und sein Kürzel dran geschrieben hat.
Nun kann man an E-Mails im Gruppenpostfach dieses Kürzel setzen und ist dafür zuständig. Jede/r setzt es selbst! Andere setzen nicht das Kürzel für jemanden. Man deligiert auch in Konferenzen keine Aufgaben an Abwesende!
Wir schauen gemeinsam 1x am Tag dort rein und ansonsten wenn da mal E-Mails reinkommen.
Man sollte die E-Mail für die man zuständig ist in etwas anderes verwandeln: Eine Aufgabe im Aufgabenverwaltungssystem, eine E-Mail an die/den Anfragende/n, etc.
um die Mail zügig in einem Archivordner überführen zu können und durch das Tag bleibt man als Zuständige/r für andere sichtbar.

Privat eine andere Herausforderung

Privat habe ich nicht eine, sondern einige E-Mail-Adressen und die Anfragen sind anders. Dort konsumiere ich Informationen mehr als das ich daraus für andere Aufgaben ableite. Insofern war die größte Herausforderung erst einmal eine Ordnerstruktur in den IMAP-E-Mail-Konten zu schaffen, denn man kann über IMAP-Konten hinweg Nachrichten verschieben und das mache ich mir zunutze um alles in einem Account zu haben.

Hauptordner sind sowas wie Registrierungen (wo habe ich mich registriert), Einkauf (Paypal-, Lieferstatus-Mails etc), … Mit Unterordnern existieren nur wenige Hauptordner. Nennen wir sie mal Gruppenordner, wie Lern- und Wissen, Arbeitsgruppen, Projekte …

Ich habe dann für die wenigen Gruppenordner eine Unterstruktur erschaffen, die aus den ~10000 E-Mails, die da waren in den vielen E-Mail-Konten abgeleitet (so passt das zu meinen E-Mail-Inhalten) und immer folgendes entschieden

Löschen oder Behalten?
Wenn beahlten: Sofort Aktion draus ableiten oder für später markieren?
Wenn für später markieren, dann Kategorie setzen: Dringend, Wichtig, Lernkurse, … UND in einen Ordner verschieben
Wenn sofortige Aktion, dann habe ich das auch sofort erledigt, selbst wenn die E-Mail nur an DEVONthink überführt wurde

Es hat ein Wochenende gedauert, aber die seit Ende der 90er niemals aufgeräumten Dinge sind nun abgearbeitet und die ganzen IMAP-Konten sind auf 0-Eingangsmails.

Seit einer Woche halte ich das auch und habe schon etliche Mailinglisten abbestellt, die einfach keinen Mehrwert (mehr bringen). Das hatte ich im Zuge der DSGVO-Inkraftsetzung schon gemacht, aber nun eben noch mal verfeinert.

Tipp: Einfach anfangen!

5. QS Barcamp der Software Testing User Group Hamburg

Kurzthesen zur Zukunft des Softwaretestens

Im Rahmen des GFFT Symposiums „Zukunft des Softwaretestens“ wurde ich gebeten meine Thesen einmal als „Kurzvortrag“ kund zu tun (5 Min.)…

Mindset statt Tools

Erst wenn auf allen Ebenen der Wertschöpfungskette verstanden worden ist, dass der Test, die Prüfung zum alltäglichen Geschäft gehört, haben auch wir in der Software „verstanden“. Andere, wie Lebensmittel- und Arzneimittelhersteller wissen um die Schlagkraft des einzelnen Mitarbeiters, darum bilden sie auch extrem gut aus.

Vorgehen & Methodenkoffer anstatt Werkzeugkoffer

Test-Vorgehen und -Methoden müssen verinnerlicht werden wie das Einschalten des Rechners am Morgen. Es wird nach wie vor zu sehr auf ein Werkzeug geschaut, anstatt die Anforderungen zu ermitteln und dann eine Entscheidung zu treffen. Sicherheitstests sind beispielsweise nicht „On-Top“, sondern Basisbestandteil täglichen Arbeitens. Förderung des Wissens um die neuen Methoden der Sicherheitstests – von Anfang/Anforderung an.

Standards anstatt Abschottung

Schaut man auf die Industrien, wo die Standardisierung der Zubehörteile und tlw. auch der Software weit fortgeschritten ist, ändert sich natürlich die Testtiefe. Die Basis (Standards) werden durch alle gleichermaßen sichergestellt, während die Geschäftsprozesse meistens individuell sind und einer tieferen Betrachtung unterzogen werden. Geschäftsgetriebene Test(Automatisierung) wird so gefördert.

Transzendente Qualität trifft transzendente Agilität

Prof. Dr. Jochen Ludewig hielt auf der TAV (Fachgruppe Test, Analyse und Verifikation von Software) Fachtagung im Jahre 2016 in Bremen mal einen Vortrag über Software-Qualität – Zwischen hohem Ziel und hohler Floskel.

Ich fand es sehr spannend in kurzen Ausflügen zu erfahren, dass eben die modelierte Qualität die unnatürlichere, aber eben die meßbare, kontrollierbare ist und die transzendente Qualität, nicht meßbar, aber dafür die ist, die uns begeistert. Er nahm das Beispiel der Schwarzwälderkirschtorte, die man nicht vermessen würde, sondern eben sagt, dass sie eben (oder eben nicht) ausgezeichnet war.

Wenn wir nun immer nur die meßbare Qualität nehmen, was verlieren wir dann?

Wir verlieren die unmittelbare Verbindung zur erlebten Qualität, damit auch den Blick auf denjenigen, der die Qualität erlebt (das Objektive verdrängt das – wichtigere – Subjektive.)
„Software Qualität – Zwischen hohem Ziel und hohler Floskel“ (2016)

Die Qualitätsprüfung, die wir benutzen, kann aber nur so gut sein, wie das unterliegende Modell und wird immer von dem natürlichen, was wir empfinden, (mehr oder weniger stark) abweichen.

Im agile Kontext wird die Meßbarkeit auch gerne vorne hin gestellt, also das Modell… Wie auch bei der Qualität…

Mit anderen Worten: Die modellierte Qualität bedarf stets der Kontrolle und Bestätigung durch die transzendente Qualität.
„Software Qualität – Zwischen hohem Ziel und hohler Floskel“ (2016)

Im agilen Kontext sehe ich dieselbe Herausforderung: Man muß sich im agilen Vorwärstkommen anhand von Kenngrößen auch bedenken, dass die Beteiligten „begeistert“ sein sollten, damit sie den Wandel mit tragen. Da spielen aber Kenngrößen keine Rolle, sondern das Empfinden und die Emotionen. Innerlich bewerten wir eben das Gefühl, ob man sich in der neuen Rolle und der gestellten Herausforderung wohlwollend gegenübersteht. Messen kann man das nicht, sondern die Schwarzwälder Kirschtorte muss schmecken, auch wenn es manchmal diverser Anläufe braucht.

„Agile Softwareentwicklung ist ein Vorgang, bei dem Projekte in Iterationen unterteilt werden. Das Ergebnis einer jeden Iteration wird beurteilt und dazu genutzt, den Zeitplan neu zu bewerten, Features werden nach ihrem Geschäftswert implementiert, damit die wichtigsten Dinge zuerst umgesetzt werden. Die Qualität sollte so hoch wie möglich sein. Der Zeitplan wird vornehmlich dadurch gemanaged, dass sich der Umfang des Projekts ändert.
Das ist agile Software Entwicklung.“
„Clean Agile, Die Essenz der agilen Softwareentwicklung“, Robert C. Martin „Uncle Bob“, 1. Auflage, 2020 S. 47

Der „Geschäftswert“ ist nicht immer in Geld auszudrücken, wenn es bspw. darum geht Kunden zu Fans zu machen¹, denn dort kommt man über Emotionen. Natürlich ist das Endergebnis irgendwann meßbar (mehr treue, zahlende Kunden o.ä.), aber man muß manchmal auch „Umwege“ über nicht sofort meßbare ~~Kennzahlen~~ Wege gehen und diese sollten also nicht immer im Vordergrund stehen.

Mehr Ehrlichkeit (= Einsicht), Disziplin und Demut wären gut. Aber Disziplin bedeutet nicht, der Bürokratie zu dienen.
„Software Qualität – Zwischen hohem Ziel und hohler Floskel“ (2016)

Wenn also der reine Fokus auf die meßbare Qualität und meßbare Agilität gelenkt wird, glaube ich, verlieren wir die Verbindung zur erlebten [Lebens-] Qualität. Wir dienen dann der Bürokratie, weil jemand die Kennzahlen haben möchte.

Die Rückbesinnung auf ursprüngliche Formen (Qualität und Agilität) sollten wir am Softwareentwicklungsprozess beteiligten Menschen ab- und an mal mitgeben (Retrospektiven), denn das Produkt sollte nicht gut vermessen sein, sondern den Kunden und die am Erstellungsvorgang beteiligten Menschen begeistern…

¹ Empfehlung: "Das Fan-Prinzip", Roman Becker, Gregor Daschmann, 2. Auflage, 2016

Kategorie: Arbeitswelt