Um ein umfassenderes Bild davon zu vermitteln, was Qualität und Built-in Quality bedeutet, habe ich beschlossen, ausgewählte Expert:innen aus verwandten Disziplinen zu ihren Ansichten zu diesen Themen zu befragen.
Es ist mir eine grosse Freude, diese Blogpost-Serie mit meinem grossartigen ehemaligen Kollegen und „Qualas“-Kumpel, Rodrigo Oliveira, in seiner Rolle als Software-Ingenieur/Entwickler zu beginnen.
(Das nachfolgende Gespräch wurde in Englisch geführt und automatisch ins Deutsche übersetzt.)
Pia:
Hallo, Rodrigo und willkommen in der Sendung!
Danke, dass du dir die Zeit genommen hast, mit mir über Built-in Quality zu sprechen. Bevor wir loslegen, stell dich bitte kurz vor.
Rodrigo:
Ich freue mich, dass ich hier sein darf, danke für die Einladung.
Ich heisse Rodrigo und komme ursprünglich aus Brasilien, das ich 2015 verlassen habe, um den amerikanischen Traum als Software-Ingenieur zu verwirklichen.
Meinen ersten Job bekam ich 2006 und da habe ich unerwartet angefangen, professionell Code zu schreiben. Damals studierte ich Wirtschaftsingenieurwesen und suchte einen Job im Finanzwesen. Als ich die Stelle bekam und feststellte, dass in dem Job täglich viele operative Aufgaben erledigt werden mussten, fragte mich mein Vorgesetzter, ob ich einen Teil davon durch Code automatisieren könnte. Ich sagte, ich würde es versuchen; man kann wohl sagen, dass es mir Spass gemacht hat, denn seitdem mache ich es immer noch!
Nachdem ich fünf Jahre in den USA gelebt hatte, lief mein Visum aus und ich bekam eine Stelle in Portugal, das schliesslich mein nächstes Ziel war. Dort hatte ich das Vergnügen, dich kennenzulernen, da wir beide für die Zühlke-Gruppe arbeiteten.
Jetzt bin ich in Kanada, weil ich endlich meinen Traumjob bei Amazon gefunden habe. Ausserdem liebe ich das Thema Qualität, und du hast sicherlich viel dazu beigetragen, dieses Interesse zu wecken.
Pia:
Danke, das freut mich zu hören.
Wie du schon sagtest, haben wir uns bei der Zühlke kennengelernt und sind durch unsere Leidenschaft für Qualität ziemlich schnell zusammengekommen, was uns auch heute hierher gebracht hat.
Das Thema Qualität und der Ausdruck „Built-in Quality“ sind heutzutage in vielen Unternehmen sehr präsent. Es gibt jede Menge Theorie, Blogs und anderes Material zu diesem Thema. Da ich aber kein grosser Fan von Theorie bin, möchte ich heute gerne deine Meinung als Software-Ingenieur dazu hören.
Was ist deine persönliche Interpretation von Qualität? Was bedeutet sie für dich? Welche Erfahrungen hast du mit Built-in Quality gemacht? Was hältst du von Schlagwörtern wie „Built-in Quality“?
Rodrigo:
Ich werde dir sagen, was ich davon halte, denn ich habe noch nie von einem Framework namens Built-in Quality gelesen. Also werde ich mich auf den Namen stützen.
Wenn ich in einem Software-Entwicklungsteam war, kam es mir immer komisch vor, dass es Entwickler und Tester gab, die eigentlich Entwickler waren.
Ich spreche nicht von manuellen Testern oder QS-Leuten, die sich wie Berater verhalten und dir sagen, wie du Qualität erreichen kannst und solche Dinge. Ich spreche eher davon, dass ein Entwickler den Code schreibt und der Tester dann den Test für diesen Code schreibt. Das hat sich für mich nie richtig angehört.
Ich persönlich dachte als Softwareentwickler immer, dass das Testen meine Aufgabe ist. Es ist Teil meines Jobs. Und ich würde sogar behaupten, dass es noch wichtiger ist als das Schreiben von Code. Denn Code ist nicht wirklich fertig, wenn du ihn nicht testest. Wie kannst du beweisen, dass er funktioniert?
Ich versuche immer, meine Tests so früh wie möglich zu schreiben. Deshalb bin ich der Meinung, dass es keinen Unterschied zwischen Softwareingenieuren und Testern geben sollte. Es sollte das Gleiche sein. Jeder Software-Ingenieur sollte also ein Tester sein.
Bei Amazon funktioniert das im Moment so und ich bin sehr froh darüber.
Die praktische Arbeit des Testens gehört allen. Die Produktmanager schreiben Testfälle mit Hilfe von Gherkin. Die Entwickler setzen sie dann um. So funktioniert es, und aus meiner begrenzten Erfahrung scheint es ziemlich gut zu sein.
Das ist meine Vorstellung von Built-in Quality. Wenn du nicht über Qualität nachdenken musst. Sie ist bereits in deinem Prozess verankert. Sie ist einfach ein Teil davon. Wenn du eine Story erstellst, ist bereits ein Test in der Story definiert. Alle sind bereit, Tests zu schreiben, und du musst sie nicht daran erinnern: „Hey, hast du das Ding getestet?“ „Natürlich habe ich es getestet... das ist mein Job“.
Pia:
Ich freue mich sehr für dich. Das klingt grossartig!
Könntest du auch ein bisschen aus deiner Vergangenheit erzählen? Vielleicht wie es nicht funktionieren sollte? Was waren deine Berührungspunkte in der Vergangenheit mit dem Testen und der Qualitätssicherung?
Rodrigo:
Auf jeden Fall. Eine frühere Erfahrung, die ich gemacht habe und die überhaupt nicht gut funktionierte, war, als wir versuchten, den Sweet Spot der Teamzusammensetzung zu finden.
Wir hatten einen technischen Leiter, zwei bis drei Software-Ingenieure und ein bis zwei Software-Ingenieure im Testing. Das war die Formel, die das Unternehmen verwendete.
Der Produktmanager warf einfach eine Idee vor. Der Engineering Manager setzte Prioritäten anhand einer Roadmap, um sicherzustellen, dass wir keine technischen Schulden anhäuften, aber zu diesem Zeitpunkt dachte noch niemand an Tests. Dann werfen wir das Feature ins Team. Der Tester muss sich überlegen, wie er es testen kann, während die Ingenieure daran arbeiten.
Irgendwann verlangten die QA-Leute, also die Softwareingenieure in der Qualitätssicherung, mehr Einblick in ihre Arbeit. Also hiess es: „Okay, lasst uns eine neue Lane auf der Kanban-Tafel für das Testen einrichten.“ Und dann: „Oh nein, eine Lane reicht nicht aus... Lass uns ein Ticket für Tests erstellen.“ Wir hatten also ein Ticket für die Umsetzung der User Story und ein weiteres Ticket für die Umsetzung des Tests. Und ich sagte: „Macht das nicht!“. Und so entstand ein natürlicher Engpass. Tests waren Bürger zweiter Klasse, und wenn man etwas abliefern musste, opferte man immer die Tests. Die Leute dachten: „Das Feature ist fertig... Es funktioniert auf meinem Rechner... Lasst es uns veröffentlichen.“. Daraus ergaben sich viele Probleme.
Pia:
Das klingt wirklich schlimm. Das muss sehr frustrierend sein. Durftest du als Entwickler damals keine Tests schreiben, weil diese Aufgabe den Ingenieuren im Test vorbehalten war, oder wie bist du damit umgegangen?
Rodrigo:
Bei dieser speziellen Stelle war ich kein Entwickler, sondern ein technischer Leiter. Und das, obwohl ich eigentlich Entwickler sein wollte. Die Entwickler waren also nicht wirklich daran interessiert, Tests zu schreiben. Ich weiss nicht, warum, denn ich kann mir keinen Grund vorstellen, warum man keine Tests schreiben sollte. Das ist doch Programmieren, oder? Das ist dein Job. Du schreibst Software. Es ist das Gleiche, nur mit einem anderen Ziel.
Ich habe nie verstanden, warum sie das nicht mögen. Ich vermute, wenn du versuchst, etwas zu testen, nachdem du es entwickelt hast, ist es schwer zu testen, wenn du es nicht gut gebaut hast.
Du versuchst zu testen und siehst, dass es nicht funktioniert. Es gibt einen Haufen Abhängigkeiten und das Ganze ist ein grosser Schlammball.
Ich habe keine Dependency Injection oder etwas Ähnliches. Dann heisst es: „Ja, ich habe es vermasselt... Ich teste nicht... Ich überlasse es den Testern, und die können in einer Integrations- oder End-to-End-Umgebung testen, denn ich kann keine Unit-Tests schreiben.“ Das war mein Eindruck. Und da es schwer zu testen war, hat das das Problem nur noch vergrössert. Die Tester waren überfordert, weil alles so schwierig zu testen war. Testen wurde nie in Betracht gezogen.
Pia:
Wow... war das der Hauptgrund, warum du das Unternehmen verlassen hast?
Rodrigo:
Nein, um ganz ehrlich zu sein, bei allen Unternehmen, die ich verlassen habe, lag es nicht an den Unternehmen. Vielmehr wollte ich einen besseren Ort zum Arbeiten und Leben finden, was auch ganz gut geklappt hat.
Pia:
Ja, es klingt wirklich gut, wo du jetzt bist.
Kannst du uns nach diesem ersten Monat in deinem neuen Unternehmen ein bisschen mehr darüber erzählen, wie es in dieser riesigen Organisation läuft? Wie schaffen sie es, dass sie nicht über Qualität nachdenken müssen, sondern dass sie etwas ist, das von Natur aus in die Software eingebaut ist?
Rodrigo:
Ich habe schon gesehen, dass es keinen Unterschied zwischen Testern und Ingenieuren gibt. Es ist ein und dasselbe. Bei der Einarbeitung gab es Schulungsmaterial, das sich nicht speziell mit dem Thema Qualität befasste, aber es gab ein Meme, das Morpheus aus Matrix zeigt, der sagt: „Was wäre, wenn ich dir sage, dass Ingenieure und Tester dasselbe sind?“.
Das ist die Kultur, die sie von Anfang an aufzubauen versuchen, damit wir keine Mauern zwischen diesen beiden Praktiken errichten. Sie arbeiten am besten, wenn sie gleichberechtigt in einem Team zusammenarbeiten.
Wenn ich mir die Codebasis ansehe, wird alles, zumindest in meinem Team, getestet. Natürlich sind einige Tests besser als andere. Du kannst keine Perfektion erwarten. Das ist wirtschaftlich nicht sinnvoll, aber alles wird getestet und die Builds dauern nicht allzu lange. Sie dauern zwar etwas länger, aber wenn man die Grösse des Unternehmens bedenkt, dauert der Bauprozess einige Minuten. Ich habe schon in kleineren Unternehmen gearbeitet, wo es Stunden dauerte, etwas zu bauen.
In meinem neuen Job habe ich schon erlebt, dass die Produktmanager bei Tests sehr aktiv sind. Sie schreiben Ideen auf, was sie für gute Tests halten. Sie schicken eine Tabelle mit einer Reihe von Testfällen, einschliesslich der erwarteten Ergebnisse und wo die Testdaten zu finden sind. Wenn sich alle einig sind, dass diese Tests für unsere Ziele sinnvoll sind, beginnen die Ingenieure mit dem Schreiben der Tests und des entsprechenden Codes.
Und das funktioniert. Ich habe noch niemanden gesehen, der etwas entwickelt und es nicht testet. Das kommt nicht vor. Es wird immer getestet.
Eine Sache, die mir aufgefallen ist, ist, dass die oberste Priorität, und das zieht sich wie ein roter Faden durch das Unternehmen, die operative Exzellenz ist. Sie sind eine DevOps-Organisation. Es gibt keine Unterscheidung zwischen Entwicklung und Betrieb. Die Entwickler sind auf Abruf. Du musst dich um deine Systeme kümmern, du musst die DORA-Metriken überwachen. Du bist für alles verantwortlich. Ich glaube, das ist die magische Sauce, die es Amazon ermöglicht, trotz seiner enormen Grösse unglaublich schnell zu sein. Das ist mein bisheriger Eindruck.
Pia:
Das klingt erstaunlich und zeigt, dass DevOps, wenn man es richtig umsetzt, funktioniert - und offensichtlich funktioniert es bei einem so grossen Unternehmen ziemlich gut.
Kannst du uns mehr darüber erzählen, wie dein Team DevOps im Besonderen umsetzt? Wie schafft ihr es, diese grosse Verantwortung auch für den operativen Teil zu übernehmen?
Rodrigo:
Bei Amazon haben wir das Konzept eines Zwei-Pizza-Teams. Das ist der Sweet Spot für die Grösse eines Teams. Ein Team kann man mit zwei Pizzen ernähren. In der Regel sind das weniger als 10 Personen. Meistens bewegt es sich zwischen sieben und neun Personen. In meinem Team haben wir sieben Ingenieure und einen Manager. Für uns funktioniert DevOps ganz einfach nach dem Motto „Du baust es, du betreibst es“.
Das funktioniert auch sehr gut, wenn du versuchst, deine technischen Schulden zu kontrollieren. Wir haben das Konzept der Bereitschaftsrotation. Es gibt immer mindestens einen Ingenieur, der auf Abruf bereitsteht. Diese Person ist dafür verantwortlich, auf Vorfälle zu reagieren. Wenn es zu einem Ausfall kommt oder ein Dienst sich nicht korrekt verhält, z. B. eine erhöhte Latenzzeit aufweist, haben wir dafür Alarme. Es gibt Dashboards mit einer Vielzahl von Metriken. Wir haben Alarme eingerichtet, die uns automatisch alarmieren, wenn etwas nicht in Ordnung ist, bevor unsere Kunden es merken.
Wenn Probleme von deinen Kunden entdeckt werden, schadest du deinen Beziehungen zu ihnen. Amazon ist extrem kundenorientiert. Wir tun alles, was wir können, um unsere Kunden nicht zu beeinträchtigen.
Die Rufbereitschaft besteht nicht nur darin, die Dashboards zu überwachen und auf Alarme zu reagieren, sondern es gibt auch einen separaten Rückstau für Trouble Tickets.
Die Trouble Tickets werden von internen oder externen Kunden gemeldet, um auf ein Problem hinzuweisen. Der Techniker, der auf Abruf bereitsteht, arbeitet an diesen Trouble-Tickets, wenn es keinen Vorfall gibt.
Dieser Techniker verbessert das System, zahlt technische Schulden ab usw. Wenn es keine dringenden Probleme gibt, haben wir immer jemanden, der sich auf die Verbesserung der Dienste konzentriert und sicherstellt, dass alles reibungslos läuft, während der Rest des Teams an neuen Funktionen arbeitet.
Diese Rolle rotiert jede Woche, d.h. in jedem Sprint, der zwei Wochen dauert, haben wir zwei Ingenieure auf Abruf. In der ersten Woche einer, in der zweiten Woche ein anderer. Ich glaube, das funktioniert ziemlich gut.
Pia:
Cool, das klingt toll.
Was mich noch interessiert: Habt ihr verschiedene Umgebungen? Wo integriert ihr oder passiert das direkt in der Produktion? Wie läuft der Integrationsprozess ab?
Rodrigo:
Das ist sehr interessant, und es hat mich ziemlich überrascht.
Wenn man einen so grossen Kundenstamm hat, muss man vorsichtig sein. Man will keine Ausfälle haben.
Deshalb hat unsere Pipeline Phasen. Es gibt viele Umgebungen, aber es gibt nicht so etwas wie „jetzt muss jemand den Build in der Staging-Umgebung validieren“ und erst danach geht es in die nächste Phase. Alles ist automatisiert.
Um den Aktionsradius zu verringern, wird die Bereitstellung nach Regionen aufgeteilt. Jede Region ist in kleinere Teile aufgeteilt. Nehmen wir an, du hast eine Region in Nordamerika. Bevor du den Code für die Flotte in Nordamerika bereitstellst, stellst du ihn für einen kleinen Teil der Flotte bereit. Dann wird dein neuer Code nur dort implementiert und freigegeben. Du beobachtest deine Metriken und richtest Alarme ein. Wenn die Fehlerrate in diesem kleinen Teil der Produktionsflotte ansteigt, wird die Pipeline angehalten. Sie wird nicht für die gesamte Flotte in dieser Region veröffentlicht. Sie kann sogar automatisch zurückgehen, um die Kunden nicht zu beeinträchtigen.
Bevor es in die Produktionsumgebung geht, gibt es andere Testumgebungen, die ebenfalls automatisiert sind. Der Code wird dort erstellt und die Integrationstests werden dort durchgeführt. Jeder Dienst hat Instanzen, die in diesen Umgebungen laufen, und wenn du Integrationstests ausführst, sprichst du mit allen Diensten, die du in diesen Umgebungen brauchst.
Pia:
Das heisst, alle Teams haben ihre Instanzen in allen Umgebungen laufen? Es gibt keine Umgebung, in der ihr nur Simulatoren habt?
Rodrigo:
In den Testumgebungen laufen die echten Dienste, aber mit Testdaten. Es ändert sich nur die Umgebung, es gibt keine simulierten Dienste.
Wenn ich an die Grösse des Unternehmens und die Anzahl der Dienste denke, habe ich etwas anderes erwartet. Ich hatte etwas erwartet, das meiner Meinung nach besser skalierbar ist, aber vielleicht liege ich ja falsch.
Ich meine, sie wissen, was sie tun. Ich war immer der Meinung, dass Contract-Tests viel besser skalierbar sind als Integrationstests. Ich denke das immer noch, aber vielleicht lohnt es sich nicht, das jetzt zu ändern.
Pia:
Und wie lange dauert ein Deployment in die Produktion?
Rodrigo:
Es kann eine Weile dauern, weil es all diese Phasen durchlaufen muss, bis es alle Regionen erreicht. Je nach Dienst kann es bis zu einem Tag dauern.
Pia:
Ok, aber ich denke, wenn man die Grösse des Unternehmens bedenkt, ist das immer noch ziemlich gut. Ich habe schon viel kleinere Unternehmen gesehen, und die haben immer noch eine Menge manuelle Arbeit dazwischen.
Rodrigo:
Nichts ist manuell. Wenn du etwas manuell machen willst, musst du das begründen und es gibt einen ganzen Prozess, um etwas manuell zu machen, denn das ist riskant. Es kann zu menschlichen Fehlern kommen. Du musst wirklich begründen, dass etwas nicht stimmt, dass der Kunde betroffen ist und dass wir deshalb manuell eingreifen müssen.
Pia:
Wenn es einen Showstopper gibt, wie schnell kannst du dann eingreifen? Wenn zum Beispiel ein Dienst in Nordamerika ausfällt.
Rodrigo:
Du hast immer die Möglichkeit, im Notfall manuell einzugreifen. Das hängt auch vom Dienst ab, aber du kannst so schnell wie möglich bereitstellen. Du kannst, wenn nötig, alles überspringen, aber du musst dich rechtfertigen und brauchst die Genehmigung eines Senior Engineers.
Selbst bei Code-Reviews kannst du, wenn du einen Pull Request schickst, sagen: „Ich will nicht, dass er überprüft wird. Ich möchte das jetzt zusammenführen".
Als Ingenieur musst du niemanden anrufen und sagen: „Bitte genehmigen, ich habe einen Notfall“. Du kannst einfach genehmigen, zusammenführen und dann begründen, warum du das tust. Natürlich wird niemand diese Funktion missbrauchen, aber es ist wichtig für uns, dass wir schnell handeln können, wenn es brennt.
Pia:
Vielen Dank für diese Einblicke. Wir haben einen sehr guten Eindruck davon bekommen, wie du über das ganze Thema Qualität denkst, welche Erfahrungen du gemacht hast und wo du heute stehst.
Was sind aus deiner Sicht die wichtigsten Erfolgsfaktoren, um eine hochwertige Software zu gewährleisten und Qualität von Anfang an einzubauen?
Was möchtest du unseren Leser:innen mit auf den Weg geben?
Rodrigo:
Ich möchte damit beginnen, ohne dass es eine technische Grundlage dafür gibt. Es ist wie eine Philosophie. Es geht darum, dass man nie etwas Langfristiges für etwas Kurzfristiges opfert. Ich denke, das ist der erste Punkt.
Du musst wie ein Eigentümer denken. Die Sache gehört dir. Wenn du langfristig etwas opferst, bist du derjenige, der für die Probleme auf dem Weg dorthin bezahlt. Das sollte dir eine gute Grundlage geben, um so früh wie möglich über Qualität nachzudenken. Es stimmt zwar, dass es so aussieht, als würdest du weniger Zeit in die Entwicklung neuer Funktionen investieren, aber diese Anfangsinvestition zahlt sich schon nach wenigen Monaten aus. Wenn du das konsequent durchziehst, hast du bereits die Gewinnzone erreicht, und es ist viel schneller, so zu arbeiten als andersherum. Ich stelle fest, dass bei manchen Projekten die Qualität nicht an erster Stelle steht, und dann geraten sie in einen Teufelskreis. Du kommst zu spät, weil du keine Qualität hast, und dann hast du keine Zeit mehr, sie zu verbessern, weil du Funktionen vorantreiben musst. Dieses Problem wird immer grösser, bis du nicht mehr weiterkommst. Und dann kannst du die Maschinen nicht ein Jahr lang anhalten, um das Zeug zu reparieren. Das ist nicht möglich. Kein Unternehmen kann sich das leisten, und das ist ein Problem, das ich sehe.
Von der technischen Seite her glaube ich, dass Ingenieure und Tester das Gleiche sind. Das habe ich schon immer geglaubt, und ich glaube, wenn wir versuchen, eine Grenze zwischen diesen beiden Rollen zu ziehen, schaden wir nur unserem Beruf und dem Projekt. Es gibt keinen Unterschied. Um Software zu entwickeln, brauchst du Qualität. Das ist ein Teil der Softwareentwicklung. Es gibt kein „Ich baue die Software, du sorgst für ihre Qualität“. Das macht keinen Sinn. Kannst du dir vorstellen, dass andere Branchen das tun? "Okay, ich baue nur das Auto...Ob es sicher ist ... geht mich nichts an ... dafür habe ich einen Tester. Das ist der Job eines Crashtest-Dummys"...„Waaaaas???“
Warum machen wir das also bei Software? Nur weil sie nicht greifbar ist? Das fühlt sich nicht richtig an.
Pia:
Ja, absolut. Ich mag das Beispiel mit dem Auto sehr. Das ist ein tolles Bild, das jeder versteht.
Vielen Dank, dass du dir die Zeit genommen hast, deine Gedanken zu teilen. Noch ein paar letzte Worte?
Rodrigo:
Hört auf, Grenzen zu ziehen. Ingenieure und Tester sind das Gleiche. That's it.
Comments