Wie Google Software testet – die Rolle des Entwicklungsteams

Neben den Features einer Software hat die Qualität der Produkte eine überragende Bedeutung. Viele von Ihnen kennen noch den alten Ansatz, der daraus besteht, Qualität in das Produkt hineinzutesten.

Viel sinnvoller ist es aber, die Produkte gleich qualitätsgerecht zu entwickeln. Besonders vielversprechend ist eine Organisationsform, die die Qualität im Entwicklungsteam anordnet.

Sie werden es glauben, oder nicht: Die Google Suche, und dort insbesondere die erweiterte Suche sieht zwar einfach aus. Es ist aber bei Weitem nicht so tivial, wie es aussieht, diese Funktionalität zu testen. James Whittaker von Google beschreibt im Testing Blog mehrere Teile des Qualitätsprozesses der Firma Google.

Die Artikelserie besteht aus mehreren Artikeln. Heute hat es mir der erste Teil der Serie angetan, bei dem es um die Philosophie geht (siehe → How Google Tests Software – Part One).

Der alte Ansatz

Den alten Ansatz der Softwareentwicklung kennen Sie vom Frühstückstoast. Er lautet „Du verbrennst den Toast – Ich kratze ihn sauber“. In die betriebliche Realität übersetzt, könnte man auch sagen: „Die Entwicklung entwickelt, und das Qualitätswesen testet solange, bis die Fehler beseitigt sind“.

Wenn auch Sie dieser Satz an das oben gezeigte Video erinnert, haben Sie die alte Methode vielleicht sogar selbst kennengelernt.

Einige Vorteile sind schnell aufgezählt:

  • Die Tester sind qualifiziert, und können ausgefeilte Methoden anwenden
  • Entwickler können sich auf das Entwickeln konzentieren

Die Nachteile lassen sich aber auch finden:

  • Mangelndes Qualitätsbewußtsein in den vorgelagerten Abteilungen, wegen fehlender Rückmeldungen
  • Fehler werden sehr weit am Ende entdeckt
  • Langsam und teuer
  • Nicht richtig motivierend, sowohl für die Entwicklung, als auch die Testingenieure

Die neue Methode

Bei Google ist das Entwicklungsteam verantwortlich für die Qualität. Die Tester haben lediglich die Aufgabe, die Entwickler methodisch dabei zu unterstützen, die Tests zu planen und durchzuführen. Der Vorteil dieser Vorgehensweise ist einfach: Die Verantwortung wird dorthin angeordnet wo sie hingehört (siehe → How Google Tests Software – Part One).

Yes, that’s right: at Google it’s the product teams that own quality, not testers. Every developer is expected to do their own testing. The job of the tester is to make sure they have the automation infrastructure and enabling processes that support this self reliance. Testers enable developers to test.

What I like about this strategy is that it puts developers and testers on equal footing. It makes us true partners in quality and puts the biggest quality burden where it belongs: on the developers who are responsible for getting the product right.

Es sind deshalb unterschiedliche Aufgaben von einem Produktowner, und dem Scrum Team zu leisten.

Planung

Einmal ist es notwendig für jede Entwicklungsaufgabe auch die notwendigen Qualitätsaufgaben zu planen. Diese bestehen meistens aus Tests zum Prüfen der Qualität der neuen Entwicklung, sowie aus Regressionstests, die dazu verwendet werden, die Funktionen der existierenden Software tournusmäßig zu prüfen (Schliesslich soll die neue Funktion so entwickelt werden, daß die existierende Software immer noch läuft).

Definiton of Done

Die Done Kriterien sind notwendig, damit der Produktowner entscheiden kann, ob ein Backlog Item erledigt ist, oder nicht. Mit den Done Kriterien werden standardisierte Qualitätsregeln festgelegt, die jeder Entwickler einhalten muss. Oft geben sich Teams eigene Kriterien.

Knowledge Transfer

Gerade am Anfang sind die Entwickler noch relativ unbelesen in den üblichen Techniken der Qualitätssicherung. Daher sollten gerade am Anfang Aufgaben vorgesehen werden, über die es gelingt, das Team in die Testthemen einzuarbeiten.

Reporting

Ein wichtiges Element ist die offene und transparente Rückmeldung, die das Team benötigt, um den Qualitätsstatus jederzeit zu verstehen. Es ist daher notwendig Backlog Items vorzusehen, die genau diesem Reporting gewidmet sind.

Weiterführende Informationen

… auf www.Produkt-Manager.net

In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:

Kontakt

Das Original dieses Artikels ist auf Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:

Comments are closed.