Sind wir wirklich nur Testmanagerinnen?

Von Natalie Volk, Finn Lorbeer, Diana Kruse, und Torsten Mangner

Bei otto.de gibt es in jedem Cross-Functional-Team mindestens eine Testerin / Testmanagerin / QA / QSlerin… wie auch immer man die Rolle der Person bezeichnet, die Bewusstsein für Qualität schaffen soll.

Bisher dominierte die Bezeichung „Testmanagerin“ – ein sehr hölzerner, bürokratisch klingender Titel. Dieser sollte deutlich machen, dass die Rolle mehr tut, als nur Tests durchzuführen: Sie managed Tests! Mittlerweile ist auch das managen von Tests nur noch ein kleiner Teil des Mehrwerts, den wir im Team erbringen.

Im Rahmen eines größer angelegten Workshops wurde unter anderem dieser Widerspruch von Zweien unserer „Testmanagerinnen„, Finn und Natalie, aufgegriffen und bearbeitet. Schnell wurden wir uns einig, dass es nicht mehr reichte, das Wort „agile“ vor Testmanagerin zu schreiben. So entstand ein neues Rollenverständnis, welches im Detail so aussieht:

 

coaching

Wir agieren als Quality-Coach des Teams

Wir unterstützen die Teams, Qualität als gemeinschaftliche Verantwortung zu verstehen. Das tun wir nicht durch Vorträge über allgemeine Konzepte, sondern insbesondere durch die tägliche, intensive Zusammenarbeit mit allen anderen Rollen im Team. Dabei etablieren wir Wissen sowie geeignete Vorgehensweisen rund um das Thema Qualität.

lifecycle

Wir begleiten den kompletten Story-Lifecycle

Wir sorgen gemeinsam mit dem ganzen Team dafür, dass unser hoher Anspruch an Qualität schon lange vor der Entwicklung unserer Produkte berücksichtigt wird.

Während der Konzeption einer Story zeigen wir alternative Wege auf und weisen auf eventuelle Risiken hin. Wir vermeiden spätere Edge-Case-Probleme, in dem wir sie schon bei der Erstellung der Story bedenken. Im Verlauf der Implementierung pairen wir mit Entwicklerinnen, um die richtigen Dinge an der richtigen Stelle zu testen. Bei der Abnahme haben wir dadurch mehr Zeit uns noch einmal mit unseren Stakeholdern und Nutzern auszutauschen. In der Produktion beobachten und bewerten wir unsere Software durch ein geeignetes Monitoring und Alerting.

continuous

Wir treiben Continuous Delivery / Continuous Deployment

Wir bringen unsere Deployments möglichst risikoarm in die Produktionsumgebung. Dafür halten wir unsere Änderungen so klein wie möglich und rollen jeden einzelnen Commit automatisiert aus. Wir verwenden dabei Feature-Toggles, um unabhängig von Code-Änderungen neue Funktionalitäten ein- und auszuschalten.

Das hat zwei zusätzliche, große Vorteile: Wir können unsere Software blitzschnell an unsere Kunden ausliefern und erhalten schnelles Feedback über neu entwickelte Komponenten.

pyramid

Wir balancieren die unterschiedlichen Testarten der Testpyramide

Wir wissen, was man auf welcher Ebene der Testpyramide testet. Wir können uns an ihr orientieren, um viele schnelle Unit-Tests, eine angemessene Anzahl an Integrationstests und so wenig End-to-End-Tests wie möglich zu erstellen. Dadurch können wir nicht nur unsere Pipelines beschleunigen, sondern unsere Tests auch möglichst effektiv und wartungsarm ausführen.

Wir finden in unserem Werkzeugkasten außerdem verschiedene Testarten (wie Akzeptanz- oder Featuretests, Explorativ), Methodiken (z.B. Test-First, BDD) und Frameworks (z.B. Selenium, RSpec). Dabei setzen wir die jeweilige Art, Methode und Framework auf allen Leveln der Testpyramide geeignet ein.

 

agile

Wir helfen dem Team die richtigen Methoden für hohe Qualität einzusetzen

Als Spezialistinnen kennen wir die Vor- und Nachteile von verschiedenen Methoden und können sie im Team erfolgreich etablieren. Dabei haben wir gelernt, dass Pairing im Team zu einer größeren Wissensstreuung, mehr Kommunikation, schneller Softwareentwicklung und höherer Qualität führt. Neben dem pairing ist die testgetriebene Entwicklung eine der Schlüsselmethodiken um unser Produkt von Anfang an mit hoher Qualität zu erstellen.

Flexible Software entsteht nur in flexiblen Strukturen. Daher vermitteln wir unseren Teams ganz undogmatisch geeignete Prozessmethodiken. Wir können dann gemeinsam entscheiden, welche Prozesse wir tatsächlich benötigen.

pairing

Wir sind im Pairing aktiv

Wir fördern nicht nur das Pairing zwischen Entwicklerinnen, sondern haben selber Spaß am aktiven Pairing. So können wir schon während der Entstehung des Codes auf Probleme hinweisen. Um nicht erst bei der Entwicklung auf Edge-Cases zu stoßen, pairen wir gerne mit Business Designern, Analysten und UX-Designern. In der Produktion überwachen wir unsere Software in Zusammenarbeit mit DevOps.

Das Pairing mit diesen verschiedenen Rollen erlaubt uns sowohl unsere technischen als auch unsere fachlichen Fähigkeiten zu kombinieren.

challenging

Wir vertreten unterschiedliche Perspektiven

Indem wir unterschiedliche Standpunkte einnehmen, bereichern wir einseitige Diskussionen. Wir versuchen typische Denkmuster zu durchbrechen, indem wir Annahmen über Prozesse, Methoden, Features und Architekturen hinterfragen. Dabei können wir beim Erarbeiten von Problemlösungen oftmals mögliche Alternativen aufzuzeigen. Das hilft uns systematische Fehler zu reduzieren, Kostenfallen zu vermeiden und Risiken bei der Entwicklung möglichst objektiv abzuwägen.

 

communication

Wir sind Kommunikationstalente

Wir sind eine Anlaufstelle für Fragen und Informationen aller Art, sowohl innerhalb des Teams, als auch nach außen. Außerdem machen wir uns den Effekt des Flurfunks, der in großen Organisationen praktisch immer vorhanden ist, aktiv zu nutze.

Wir sehen uns als Verstärker für Kommunikation. Diese kann zwischen einem Pair statt finden, zwischen vielen oder allen Teammitgliedern und über Teamgrenzen hinweg. Durch diese Koordination können wir Unklarheiten über Features oder Integrationen erheblich reduzieren und unsere Produkte somit schneller bis zur Produktionsreife entwickeln.

 


 

Im nächsten Schritt wurde dieses neuen Rollenverständnis mehr und mehr unserer „agilen Testmanagerinnen“ vorgestellt, welche auf Anhieb derart begeistert waren, dass sie sich am liebsten gleich nochmal auf die Stelle bewerben wollten. Was noch fehlte, war ein passender Name. In jedem unserer Cross-Functional-Teams gibt es verschiedenste Spezialisten. Einer dieser Spezialisten ist die treibende Kraft für mehr Qualität: der Quality Specialist.

specialist
Quality Specialist“ ist eine sehr passende Bezeichnung für diese gewachsene Rolle. Auch wenn sie fast immer sehr ausgeprägte Generalistinnen sind, liegt ihre eigentliche Stärke im Schaffen von Bewusstsein für Qualität.

Das waren die ersten Schritte auf einer nun beginnenden, spannenden Reise. Als nächstes werden wir mit den anderen Rollen in den Teams erarbeiten, was die Veränderungen für unseren Alltag und unsere Zusammenarbeit im Detail bedeutet. Wir wissen außerdem, dass wir diese Rolle bisher noch nicht komplett erfüllen. So werden wir nun in diese Aufgabe hineinwachsen, über die Veränderungen unserer Rolle reflektieren und darüber hinaus kontinuierlich in verschiedenen Feldern unterschiedlich viel dazu lernen.

Tagged with: , ,
Veröffentlicht in Testing
8 comments on “Sind wir wirklich nur Testmanagerinnen?
  1. Britta sagt:

    Ich möchte mit und bei euch arbeiten! 🙂 Den Titel „Quality Specialist“ finde ich sehr passend und ja, als Tester müssen wir Kommunikationstalente sein.
    Toller Artikel und viel Erfolg auf eurer Reise als Quality Specialist!

  2. […] Quelle: Sind wir wirklich nur Testmanagerinnen? | dev.otto.de […]

  3. Finn Lorbeer sagt:

    For the english reader: here is a translation of the article: http://www.lor.beer/are-we-only-test-manager/

  4. spallepogu sagt:

    It’s a good artikle.

  5. […] Was kann man als Testmanager tun? Prozess definieren? Nein, denn einen Prozess definieren, per Mail rumschicken und hoffen dass es klappt funktioniert nicht. Die Technologie dafür bereitstellen? Nein, das machen die Entwickler. Eine Kultur der Qualität erschaffen? JA! Testmanager sind analytische Köpfe und schaffen es durch Coaching und permanentes Lernen ihr Wissen weiter zu vermitteln. Außerdem können sie ihr Team motivieren und zu Challenges anstacheln. Man sollte im Unternehmen ein Quality Mindset erstellen, damit alle von Anfang an an die Qualität denken und sie nicht erst am Ende draufgesetzt wird. Dazu gibt es einen sehr interessanten Artikel auf dem Otto Entwickler Blog. […]

  6. […] Quality Specialists schauen nicht nur über den teameigenen Tellerrand, indem wir uns in bereichsweiten Formaten wie […]

  7. […] watch the whole release process in many complementing roles. More on all of them can be found at dev.otto. I think that the job title they invented – Quality Specialist – is really matching… and […]

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: