Vortrag zur Ethik -- German Testing Day 2016

Das Thema Ethik ist en vogue auf den Veranstaltungen zum Testing. Das ist auch gut nachzuvollziehen durch immer mehr autonome Systeme in unserer Umwelt, die unter Umständen selber über Leib und Leben entscheiden müssen (autonomes Auto, dass möglicherweise einen Unfall hat).

Der Referent Tobias Geyer (@the_qa_guy) hat für mich einige interessante Aspekte in seinem Vortrag gebracht. So stellte er ein paar Beispiele eines sozialen Netzwerkes dar und hinterfragte die Ethik der Vorgehensweise. Im weiteren stellte er vorhandene Codes of Ethics von IEEE, ACM und ISTQB und Testguru James Bach vor und verglich diese miteinander. Außerdem unterzog er seine Beispiele einer Prüfung bezüglich der Codes.

Seine Schlussfolgerung und sein Aufruf in der Diskussion:

• Wir sind alle als Tester mit verantwortlich für die Ethik in der Softwareentwicklung. Wir können und dürfen uns dieser Verantwortung nicht entziehen
• Das German Testing Board sollte sich der Ethik annehmen und das Thema vorantreiben 

Wir haben nach Ende des Vortrags noch intensiv die Pause für Diskussion genutzt. Dabei kamen von verschiedenen Personen unterschiedliche Statements:

• Wir brauchen eine breite gesellschaftliche Diskussion
• In recht unbekannten Gruppierungen (z. B. GTB) hat dies zu wenig Breitenwirkung
• Wenn ein Board es schafft, die Diskussion in die Gesellschaft zu tragen, wäre das super
• Der Gesellschaft scheint das Thema noch nicht wichtig genug
• Es sind nicht nur Tester, sondern alle Mitglieder von SW Entwicklungsteams für Ethik-Themen gefragt. Also auch PL, PO, ScM, Entwickler ...
• Nicht immer können Menschen Partei für die Ethik ergreifen (was wenn man Familie zu ernähren hat - kündigt man einfach? - wahrscheinlich nicht)

Inspirierend. Aufweckend. Die Diskussion ist noch lange nicht am Ende. Ich hoffe auf Fortsetzung bei weiteren Events und über soziale Netzwerke...

Vorträge am German Testing Day 2016

Bei vier parallelen Tracks muss man sich immer für einen Track entscheiden. Ein paar Statements/Ideen aus den von mir besuchten Vorträgen.

Navigieren, wo nie ein Test zuvor gewesen ist

• Session based testing sollte man für kreative Tests nutzen; diese Art fördert die Neugierde
• Der Kunde verhält sich viel öfter anders, als man sich das vorher vorgestellt hat

Das Ende des End-to-End Tests?

Ein wenig provokativ aber mit interessanter Idee war dieser Vortrag von @MSchlabinger. Im Schnitt haben 38 Systeme Beziehungen untereinander, für die man E2E Tests durchführen muss. Für eine gute Testabdeckung müssen viele Mocks und Stubs geschrieben werde. Doch diese kosten die Entwickler Zeit. Also verfällt man auf UI Tests und damit zur Ice Cream Testautomatisierung (Umkehrung der Pyramide und bekanntes Anti-Pattern). Dies ist teuer, instabil und unterliegt ständiger Anpassung. Ganz zu schweigen von der späten Durchführung. Deshalb wirbt er für eine Service-Virtualisierung. Diese basiert auf den Daten, die die Services austauschen. Diese können zum Beispiel aus "Mittschnitten" des Echtbetriebes gewonnen werden. Die Tests auf Basis der Virtualisierung können einfacher also die umfangreichen Mocks umgesetzt werden und werden damit von den Entwicklern umgesetzt. Auf jeden Falls ein Ansatz, den man überdenken sollte.

Testmanagement in agiler Transition

Der Referent @KayGrebenstein stellte seine Überlegungen vor, wie sich die Aufgaben des Testmanagers aus klassischen Projekten im agilen Umfeld wiederfinden. So konnte er darlegen, dass sich die operativen Aufgaben (Testmanager) auf die verschiedenen Rollen in einem agilen Team verteilen und aus seiner Sicht auch vollständig wahrgenommen werden. Die Rolle des Testmanagers muss damit aus seiner Sicht im agilen nicht speziell besetzt werden. Die strategischen Aufgaben (Qualitätsmanager) sind jedoch nicht im agilen Entwicklungsteam angesiedelt. Dafür muss die Gesamtorganisation sorgen. Das kann zum Beispiel durch Gilden (kommt ursprünglich von Spotify) geschehen, die sich gezielt um Themenstellungen kümmern und vorantreiben.

Gut gefallen hat mir auch das Mindset, dass in seinem Unternehmen herrscht. "Jeder ist für Qualität verantwortlich".

Keynotes auf dem German Testing Day 2016

Zwei interessante Keynotes gab es auf dem German Testing Day 2016 in Frankfurt.

Johannes Mainusch (@docjoe), der lange bei Xing und Otto als Entwicklungschef war, berichtete in der morgendlichen Keynote darüber wie sich Organisationen aufstellen sollten, um erfolgreich zu sein. Dabei kam er zu folgenden interessanten Schlussfolgerungen.

"Software Architecture fails" (jedenfalls in den letzten Jahrzehnten). Das Problem ist in der Regel, dass Architekturen nicht vertikal konzipiert sind sondern horizontal (und so weiter wachsen). Dies führt zu einer starken Abhängigkeit, die Änderungen sehr schwer wenn nicht unmöglich machen. Die Matapher dazu: "Software ist wie Fichtenholz - wenn man sie nicht frühzeitig spaltet, wird sie unspaltbar".

Zu Änderungen in der Organisation gab er folgende Erfahrungen weiter:

• Wenn ich dauernd was ändere, wird es weniger steuerbar und damit schlecht
• Leider wollen Manager dauernd was ändern - Daseinsberechtigung/vor allem bei neuen Managern
• Ändere langsam 

"Zentrale QA fails". Das Testen und die Qualitätssicherung gehören in das Entwicklungsteam. Mit dieser Aussage stützt er voll den agilen Gedanken der cross-funktionalen Teams.

"Richte die Organisation und die Teams auf das Deployment aus". Hätten wir vor 9 Jahren noch über einen Auslieferungszyklus von 2 Wochen "wow" gesagt, sind Continuous Integration und Continuous Deployment das Ziel. Einen Change durchzuführen "darf nicht weh tun" und muss in wenigen Minuten erfolgen können...

Der Blogger und Autor Tim Cole (@TCole1066) berichtete über die Aspekte des digitalen Wandels generell und in Deutschland im Besonderen. Aus seiner Sicht ist das Thema Vernetzung ein ganz zentrales Thema. Denn der derzeitige Wandel führt zu einer Vernetzung auf allen Ebenen der Technik, Systeme und der Gesellschaft. Dazu müssen wir uns auf Veränderung einstellen und diese auch gestalten.

"Du kannst nicht vernetzen ohne zu verändern".

Weiterhin ging er auf ein typisch deutsches Dilemma ein. Wir dürfen nicht nur reden und ständig diskutieren über Veränderung. Wir brauchen Mut zur Veränderung. Wir brauchen Mut für Neues.

"Wir müssen die Zukunft gestalten."

Kurzweilig (Beispiel) und eloquent vorgetragen war es eine tolle Keynote zum Abschluss des German Testing Days 2016

ASQF Testing-Day: Agiles Testen vs. ISO 29119

Einen sehr unterhaltsamen und informativen Vortrag hielten zwei Referenten der imbus AG zum Thema Agiles Testen vs. ISO 29119. Beide Referenten polarisierten geschickt mit der Zuspitzung der beiden Positionen

• Agiles Testen ist doch: "jeder macht was er und wann er will" und "da wird ja gar nichts geplant"
• ISO Norm ist doch: "da ist alles starr und fix vorgegeben" und "das lässt mir keine Freiheitsgrade"

Und eigentlich liegen beide Themen gar nicht so weit auseinander. Denn für beide Vorgehensweisen, egal ob agil oder stark an der Norm orientiert, gilt aus Sicht der Referenten:

• Nutze das aus der Norm, was interessant für das aktuelle Projekt ist (was bietet einen Mehrwert für das Projekt) - damit bietet auch die Norm Flexibilität
• Nutze eine Norm (oder Teile der Norm) als Vorlage für Verbesserungen oder auch als Vorlage für test cases
• kläre wieviel Dokumentation benötigt wird ("just enough documentation")
• wie sieht ein Testreport am Ende eines Sprints oder Meilensteines aus? wieviel muss er enthalten? kann die Norm hier Hilfestellung geben.

Nicht nur der Vortrag war kurzweilig. Auch beim Get Together waren die Referenten interessante Gesprächspartner.

ASQF Testing-Day: Test meets Security

Einen spannenden Vortrag gab es auf dem ASQF Testing Day in Erlangen. Dieser beschäftigte sich mit dem Thema des Security-Testing. Aus meiner Sicht stellte der Referent folgende Eckpfeiler dar:

• Die zunehmende Vernetzung (Fahrzeuge, Industrie 4.0, etc.) rückt die Security-Tests stärker in den Focus
• Derzeit nimmt der Referent zur IT-Sicherheit einen deutlichen Paradigmenwechsel wahr (Security wird immer wichtiger)
• Die Tests sollten sich nicht nur auf die Applikationen beziehen sondern auch die IT-Infrastruktur berücksichtigen
• Wesentlicher Bestandteil des Testens sind unit-Tests
• Schwachstellen in Applikationen setzen sich aus zwei Kategorien zusammen:
• Entwurfsfehler
• Programmierfehler
• Zur Prüfung auf Programmierfehler sollten automatisierte Fuzzing-Tests durchgeführt werden
• diese sind mit unit-Tests zu automatisieren
• so kann eine hohe Variation in den Tests erreicht werden
• dieses können zur Regression immer wieder ausgeführt werden
• Modellbasiertes Testen ist für diese Tests sehr gut geeignet und sollte in Betracht gezogen werden

Letztendlich zeigte der Vortrag, dass man bei der Entwicklung das Thema Eingaben und Dateneingabeformate immer intensiv beim Test berücksichtigen muss.

Testing, Checking oder einfach nur testen?

Der Testexperte Gojko Adzic (Link zu seinem Blog) hat in einem seiner Artikel eine interessante These aufgenommen. Die besagt, dass das Testen eigentlich aus zwei unterschiedlichen Disziplinen oder Arten besteht:

1. Das Überprüfen erwarteter Ergebnisse. In Testfällen wird beschrieben, wie sich eine Anwendung verhalten soll. Dies wird dann überprüft. Diese Disziplin wird als checking bezeichnet. Gängige Tests sind dafür Unit-Tests, Tests von Datenformaten, Datenmigrationen, Schnittstellen etc.
2. Die Analyse der Anwendung auf das Verhalten bei Nutzung. Damit wird getestet, ob sich eine Anwendung unerwartet verhält. Ob Undefiniertes und Unbekanntes auftritt. Diese Disziplin wird als testing bezeichnet. Darunter fällt z. B. usability testing und exploratives Testen.

Eine spannende Unterscheidung. Denn die Tests, die unter checking fallen, bieten sich auch stark für Automatisierung an und sind in der Regel vom Entwickler (z. B. im Pairprogramming) umzusetzen. Das testing wird dann von erfahrenen Testern manuell durchgeführt.

Agile Testquadranten

Auch im agilen Projekt muss man jederzeit in den Sprints alle Qualitätsfaktoren im Blick haben. Doch welche Tests sollten wie durchgeführt werden? Welches Ziel verfolgen die Tests? Dazu geben die vier agilen Testquadranten Auskunft:

Agile Testquadranten nach Crispin/Gregory

Im ersten Quadrant befinden sich die Tests, die Team unterstützend wirken und technisch orientiert sind. Das Test Driven Development ist eine Voraussetzung für die vielen Regressionstests, die in der agilen Vorgehensweise notwendig sind.
Im zweiten Quadranten sind die Tests aufgeführt die das Team ausführt, damit sichergestellt wird, dass die Funktionen so umgesetzt wurden, wie diese geplant waren. Auch bei diesen Tests kommt die Testautomatisierung zum Einsatz, jedoch mit deutlich geringerem Umfang. Als Vorgehensweisen kommen oft Acceptance Test Driven Development (ATDD Link wikipedia) und Business Driven Development (BDD Link wikipedia) zum Einsatz.
In den dritten Quadranten fallen die Tests, welche die Geschäftstauglichkeit des Produktes hinterfragen. Es sind die Tests, die die Software sehr intensiv aus Sicht des Endbenutzers betrachten. Diese werden manuell durchgeführt.
Die Tests des vierten Quadranten sind spezielle Tests, die oft auch Experten mit speziellem Wissen für Tests (z. B. für die Security-Tests) oder für die Werkzeuge (z. B. Last- und Performancetests) benötigen. In großen Organisationen werden diese oft in Testcentern gebündelt, damit nicht jedes Team mit hohem Aufwand die Infrastruktur und Know-How aufbauen muss.