DevOps – Testen, aber richtig! Klassisch vs. Unit Tests, TDD

Bei der Qualitätssicherung – und die besteht nun einmal hauptsächlich aus Testen – unterscheide ich zwischen dem SOLL und IST Zustand der klassischen Vorgehensweise und Unit Tests durch den Test-First Ansatz (Test-Driven-Development, TDD).

Die Vorgehensweise der Qualitätssicherung im klassischen Sinn (SOLL):

  1. Entwickler schreibt eine Methode, Klasse oder eine Applikation
  2. Wenn genug Zeit vorhanden, meistens nur optional
    • Manuelle Tests starten
    • Unit Tests erstellen
    • Integration Tests erstellen
  3. Wenn genug Zeit vorhanden, meistens nur optional
    • Es werden alle manuellen Tests von Anfang an neu gestartet
    • Es werden alle Unit Tests neu gestartet
    • Es werden alle Integrationstests neu gestartet
  4. Es werden gemeldete Fehler behoben

Die Vorgehensweise der Qualitätssicherung im klassischen Sinn (IST):

  1. Entwicklungsteam schreibt eine Methode, Klasse oder eine Applikation
  2. Es werden Fehler behoben (und ggf. ungewollt weitere erzeugt)
  3. Fehleranalyse dauert sehr lange, Kosten steigen pro Fehlerfall

Die Vorgehensweise der Qualitätssicherung bei Test Driven Development (Test-First Ansatz, ausgeführt zur Entwicklungszeit)

  1. Schreibe einen Test
  2. Starte alle Tests
  3. Stelle sicher, dass der/die Tests grün werden
    => der produktive Code muss geschrieben werden
  4. Starte alle Tests
    1. Der neue Test schlägt fehl (Red)?
      => Fehler beheben und weiter mit 4.
    2. Der neue Test ist okay (Green)
      => Produktiven Code aufräumen (Blue)
    3. Alle Tests sind okay und kein Bedarf den Code aufzuräumen
      =>  Schreibe einen neuen Test (weiter mit 1.)

Dadurch entsteht ein Zyklus, der mit einem fehlschlagenden Test beginnt (RED) und behoben wird (GREEN). Ggf. kann der Code vereinfacht und aufgeräumt werden (BLUE).
Es entwickelt sich dadurch nach und nach der produktive, aufgeräumte Quellcode – in kleinsten Schritten, überschaubar, lesbar und voll automatisiert.

Mein Fazit:
Der Idee hinter TDD steht für mehr Qualität, Stabilität, Wartbarkeit – und das zu jederzeit automatisiert per Knopfdruck

Weitere Empfehlungen zum Thema Unit Tests und Test Driven Development

Werbeanzeigen

XP, Pair Programming – Necessary business conditions (part two)

Dieser Artikel ergänzt die weiteren erforderlichen Rahmenbedingungen. Im ersten Teil ging es um ein gemeinsames Verständnis und den Nutzen eines aktiven Vorlebens. Dieser Artikel hingegen befasst sich mit den größten Herausforderungen und Hürden, die – meiner Meinung nach – zu vermeidbaren Missverständnissen führen können. Und diese kosten nicht nur Zeit, sondern stellen auch ein Risiko dar, das nicht unterschätzt werden darf.

Missverständnisse jeglicher Art sollten natürlich vermieden werden. Das klappt aber nur, wenn der Kunde und der Auftragnehmer das gleiche Verständnis für den Umfang und Inhalt der Aufgabe haben. Solche Hürden entstehen aber meistens dann, wenn eine Aufgabe oder Anforderung nicht präzise genug formuliert ist und somit Interpretationsspielraum zulässt. Damit sind den täglichen Herausforderungen Tür und Tor geöffnet, die dann meistens mehrfach vorkommen.

K.O. Kriterien, wie lassen sich solche Probleme vermeiden?
Ganz klare Antwort: offene Kommunikation im Team.
Dazu gehören akute Probleme, Herausforderungen und Hindernisse, die beseitigt werden müssen. Jedes Teammitglied sollte idealerweise einen guten Überblick über den aktuellen Stand haben, damit bei Planänderungen durch Urlaub oder Krankheit, zeitnah agiert werden kann. Es muss nicht jeder alles wissen, aber durch regelmäßige Absprachen und Informationsaustausch lassen sich zum Beispiel Aufwände bei unvorhergesehenen Vertretungen reduzieren.

Wie erreicht man im Team diese Offenheit?
Hier bieten sich regelmäßige Termine an, um die größten Herausforderungen transparent zu machen. Durch kleinere Workshops, sog. „Lessions learnt“, lassen sich Lösungswege viel schneller erarbeiten. Ein kurzes Branstorming, eine Zeichnung oder Skizzen auf dem Whiteboard eignen sich ebenfalls bestens, um ein breiteres Verständnis und Klarheit zu schaffen. Das WIR als Team muss hier an erster Stelle stehen!
Idealerweise lassen sich aus den Ergebnissen wiederum konkrete Maßnahmen ableiten, die ggf. weiter verfeinert, eingeplant und umgesetzt werden können. Nicht alles lässt sich sofort umsetzen, aber wenn eine Aufgabe erstmal benannt ist, im Team erklärt wurde, kann diese auch besser beurteilt, eingeschätzt und geplant werden.

Deswegen an dieser Stelle meine klare Empfehlung:
Sprecht die Punkte offen an, die Euch am meisten stören – sachlich, objektiv und mit Fakten hinterlegt.

Eine Buchempfehlung (neue Perspektiven und Sichtweisen)

Eine Themenübersicht – Coding Dojo bis Pair Programming

Mit den hier gelisteten Artikeln möchte ich Euch einen Einstieg in die verschiedenen Methoden der Agilen (Software-) Entwicklung geben:

  1. Coding Dojo
  2. Agil, Pairing (XP), aber was steckt dahinter?
  3. Standard Prozesse

    Glossar:

    • XP: Extreme Programming
    • Pairing: Pair Programming, ist ein Teil von XP
    • Dojo, Kata: Übung
    • TDD: Ein Methodik, die den Test-First Ansatz verfolgt
    • DevOps: Development trifft auf Operations

XP, Pair Programming – Necessary business conditions (part one)

Als nächstes widme ich mich den erforderlichen Rahmenbedingungen. Die hier aufgezeigten Punkte sind Schlussfolgerungen aus meinen persönlichen Erfahrungen und stellen natürlich kein Allheilmittel dar. Trotzdem bleibt jeder der folgenden Punkte – meiner Meinung nach – zwingend erforderlich und sollte nicht ohne wichtigen Grund über Bord geworfen werden. Was als wichtiger Grund zu verstehen ist, muss jedes Team innerhalb eines Unternehmen projektabhängig für sich selbst entscheiden.
„It depends.“

Gemeinsames Verständnis:
Zu den zentralsten Rahmenbedingungen zähle ich in einem Projekt das gemeinsame Verständnis. Nur wenn jedes Teammitglied inkl. Projektleitung, Management und Kunde von ein und demselben Aspekt, Punk bzw. Aufgabe sprechen, kann das gesamte Team als Einheit gemeinsam an einem Strang ziehen. Ansonsten entstehen ungewollte Wechselwirkungen, die sehr schnell zu Missverständnissen führen können. Diese gilt es dann zeitnah aus dem Weg zu räumen, um unnötige Termine zur Klärung zu vermeiden. Aber auch hier gilt: Es gibt keine falschen Fragen!

Bekannte Herausforderungen erkennen und meistern:
Darunter verstehe ich die Erzählungen. Projektbeschreibungen oder Anekdoten, die einem auf Konferenzen oder Fortbildungen wie User Group Treffen zugetragen werden. Zusätzlich helfen hier die selbst erlebten Erfahrungswerte, um aus ihnen zu lernen. Projektinhalte lassen sich nicht 1:1 vergleichen, aber die Prozesse zur Durchführung sind doch meistens sehr ähnlich aufgebaut.

Vergleich zwischen Theorie und Praxis – Zwei völlig unterschiedliche Welten?
Das Lehrbuch verspricht uns die schöne grüne Wiese.  Dort finden wir viele gute Empfehlungen und Vorschläge rund um den Einsatz von Agilen Methoden – sei es SCRUM, XP, Kanban o.ä.  Die Praxis schaut hier meistens etwas anderes aus. Die täglichen Herausforderungen bestehen darin, dass einem immer genau die Situationen über den Weg laufen, die nicht im Buche stehen. Wichtig ist aus meiner Sicht zu lernen, was beide Welten miteinander verbindet, um daraus einen Mehrwert für das aktuelle Projekt, sein Team und natürlich die Firma zu generieren.

Mein erstes Fazit: Und täglich grüßt das Murmeltier – oder wie war das gleich nochmal? Aber im Ernst – mit dem gemeinsamen Verständnis als Fundament lässt sich viel effizienter ein tragendes Gerüst zur Überwindung von Vorbehalten bauen. Aktives Vorleben und gemeinsames Erleben sind für mich von größter Bedeutung. Aha Effekte erzeugen, Lernen und lernen lassen nehmen einen ähnlich großen Stellenwert ein. Auch hier gilt der Klassiker – Übung macht den Meister – egal ob bei Naturwissenschaften oder Sprachen.

Literaturempfehlung:

XP, Pair Programming – unknown things, create something new due pairing!

Was man unter Pair Programming versteht habe ich hier beschrieben. Zuerst soll es um den Punkt Unbekannte Gewässer, etwas Neues wagen gehen. Dazu zwei wesentliche Fragen:

  1. Wie steigert man die Bereitschaft im Team für etwas Neues?
    Darauf gibt es eine einfache Antwort, die aber durchaus etwas Überwindung kostet: Vorleben, lasst Euer Umfeld die Begeisterung an der Sache spüren!

    Holt Eure Gesprächspartner ab, sprecht offen über Euer Vorhaben, eure Idee, eure Ziele – egal ob mit Kollegen, Freunden oder Familie! Nur wenn ihr von etwas überzeugt seid, schafft ihr es auch, andere in euren Bann zu ziehen. Ist der Grundgedanke einmal vermittelt, habt ihr bereits die Hälfte der Strecke geschafft! Der Rest ist nur noch eine Frage der Organisation und abhängig von der jeweiligen Situation.

  2. Lässt sich etwas Neues mit einem Fingerschnippen umsetzen?
    Auch hierfür gibt es eine einfache Antwort: Nein – Neue Ideen brauchen Zeit, um zu reifen.

    Man verlässt ungern seine gewohnte Umgebung. Der Weg zur Arbeit wird meistens der gleiche sein. Eine Veränderung an bekannten, geschätzten oder liebgewonnenen Dingen vermeidet man soweit wie einem möglich. Somit ist bei jeder Änderung – egal ob es nur eine Person oder eine ganze Gruppe betrifft – sehr viel Fingerspitzengefühl gefragt.
    Nicht jede Entscheidung ist sofort für alle transparent und/oder nachvollziehbar. Aber unabhängig davon, bleibt das Wichtigste, alle Personen frühzeitig abzuholen und in den Entscheidungsprozess einzubeziehen. Damit entsteht viel schneller ein breites, gemeinsames Verständnis bei allen Beteiligten.
    Nebenbei kann durch die Gruppendynamik berechtigte Kritik bewertet werden. Das trägt wiederum zur Teambildung bei – alle ziehen an einem Strang. Aus meiner Sicht ist das Glas immer halb voll.
    Bei solchen kontroversen Gesprächsrunden kann eine unabhängige Person als Moderator durch die objektive und sachliche Sichtweise unterstützen. Rund um das Thema Moderation bzw. Sicht- und Denkweisen gibt es sehr gute Fachliteratur.
    Meine Empfehlung: