#QConf2016 - SoftwareQualität - immer Thema für uns Quality Specialists - auch konzernweit

Wir Quality Specialists schauen nicht nur über den teameigenen Tellerrand, indem wir uns in bereichsweiten Formaten wie QS-OpenSpace, QS-Conventions und Fokusgruppen rund um das Thema Qualität austauschen. Wir strecken unsere Fühler auch konzernweit und über den Konzern hinaus aus.

In diesem Beitrag möchte ich kurz über die QConf sprechen, der jährlichen konzernweiten Konferenz für alle Software-Qualitäts-Interessierten der otto group.

Seit dem letzten Jahr haben sich die einzelnen IT-Bereiche stark weiterentwickelt. Konzernweit spiegelt sich in etwa das wider, was ich auch am Markt verfolge: Es gibt Bereiche, die noch am Anfang stehen, was agile Software(Qualitäts)Prozesse angeht. Andere, wie wir bei otto.de, leben und verändern diese schon seit einigen Jahren. 

Die QConf in Zahlen:

750 Feedbackzettel
70 aktive Teilnehmer
17 Stunden Softwarequalität
16 Speaker / Workshopleader
4 Sponsoren
4 Orgas
1 riesiger Raum

Jeder Bereich steht somit vor anderen Herausforderungen und doch macht uns ein Gedanke alle gleich:

"Wie können wir unterstützen, dass qualitativ hochwertige Software an unsere Kunde geliefert wird?"

Diese Frage haben wir aus unterschiedlichen Perspektiven beleuchtet, so dass es Themen gab wie „Welche Softskills brauche ich um Qualität voranzutreiben?“, „Wie bekomme ich die richtige Zuordnung in die Testpyramide hin?“, "Welche Testmanagementwerkzeuge setze ich ein und wozu?", "Was macht der Trend der Microservices mit uns?" und "Wie gelingt ein Change hin zu agilen Softwareentwicklungsmethoden?".

Mittels Vorträgen, Workshops und Zeit für den direkten Austausch der Teilnehmer konnten wir zwar keine allgemein gültige Lösung finden. Wir sehen jedoch, dass eine enge Zusammenarbeit mit Anforderern und Umsetzern einiges mehr von uns QSlern abverlangt als noch vor einigen Jahren und unentbehrlich ist.

Besonders kontrovers ging es bei der Fragestellung zu: "Wie? Ich muss jetzt Code lesen können???". Für die Teilnehmer, die sich aktuell in einem reinen QS-Team befinden, stellte sich die Frage bis jetzt eher nicht. Außer sie sind für die Testautomatisierung zuständig und codieren selbst. Somit war die Verwirrung allein über die Frage bei einigen Teilnehmern ziemlich groß.

Die Teilnehmer aus crossfunktionalen Teams hingegen waren sich einig, dass Code lesen können eine dringend benötigte Fähigkeit ist. Einer der großen Vorteile daran ist, dass man sich um einiges einfacher über Testebenen mit dem Entwickler auszutauschen kann. Beide Rollen verstehen dadurch besser, wo etwas hinreichend überprüft ist und dazu muss ein QSler nun einmal Programmierkenntnisse haben.

Dass diese Erkenntnis etliche Tester mindestens verunsichert, verstehe ich. Dies ist schließlich ein Feld, was lange nicht Aufgabe eines Testers war, ja sogar absichtlich unterbunden wurde. Im QS-Umfeld wurde lange die These vertreten, dass bei inhaltlicher Kenntnis des Codes die Objektivität verloren geht. Ganz nach dem Motto: "Entwickler testen doch eh nur das, was funktioniert!". Zu den Zeiten war es für etliche nur logisch, dass sich QSler nicht mit dem Code auseinander setzen dürfen, da man sonst in das gleiche Problem läuft. Für alle, die diese These noch unterschreiben, empfehle ich TDD zu praktizieren. Grob gesagt - für dejenigen, die dieses Vorgehen noch nicht verwenden: Man schreibt erst automatisierte Tests (aus Anforderungsperspektive) und erstellt und verändert den Programmcode danach so lange bis der Test positiv wird.

"Sind also Entwickler auch QSler bzw. andersrum?" Ja und nein. Beide sollten breites Wissen über die jeweilige Fachlichkeit haben und diese einsetzen können. Ich wehre mich allerdings dagegen, dass ein kompletter Rollentausch von Entwickler und QSler stattfinden kann. In der Tiefe unterscheiden sich die beiden dann doch, weil sie einfach unterschiedliche Blickwinkel auf die Software einnehmen.

Ähnlich facettenreich ging es bei der Frage der Testpyramide zu. Viele unterschiedliche Meinungen und Ansichten kamen zueinander. Festzuhalten ist, dass klar sein muss, um was für ein System es sich handelt und auf dieses können die einzelnen Teststufen dann angewendet werden (z.B. der gesamte otto.de-Shop ist ein System, allerdings besteht dieses aus vielen kleinen Systemen). Auf welcher dieser Stufen ist es aber sinnvoll diese oder jene Anforderung zu überprüfen? Darauf gibt es keine pauschale Antwort. Zumindest möchte ich an dieser Stelle mitgeben, dass es korrekt ist, sich aus Kundensicht zu nähern und gleichzeitig mitgeben, dass dies nicht zwangsläufig zu Tests ausschließlich in der Spitze der Pyramide führen sollte.

Besonders spannend fand ich, dass viele etwas bewegen wollen, nur oft nicht wissen, wie man startet oder dran bleibt. Vieles wurde seit der Konferenz im letzten Jahr ins Rollen gebracht und tolle Fortschritte sind zu sehen. Auch in diesem Jahr wurde viel über Change gesprochen. Und auch an dieser Stelle gibt es nicht den idealen Lösungsweg an dem man sich langhangeln kann. Allerdings wurde eines von den meisten schon verinnerlicht.

"Bei mir selbst muss ich mit der Veränderung starten!"

Da Veränderung nie aufhört, freue ich mich, dass dieses Format den Austausch von uns QSlern weiter fördert und wir weiter von- und miteinander lernen können. Vielleicht können wir dann über Fragen philosophieren wie: "Ist Testautomatisierung wirklich eine Programmier-/Entwicklertätigkeit?" oder auch "Löst ein sehr gutes Monitoring funktionale Tests komplett ab?".

Bis zum nächsten Jahr,

Eure Diana

P.S.: Eine weitere persönliche Sicht auf die QConf2016 hat die Teilnehmerin Katja in ihrem Blog veröffentlicht.