TDD & Zukunft – auf Deutsch

Von | 5. Januar 2016

Eigentlich verweise ich nur sehr ungern auf das andere Blog. Heute habe ich aber zwei Themen, und beide drehen sich darum.

TDD auf Deutsch

Ich habe letztes Jahr angefangen, über test-driven development in der Webanalyse zu schwafeln. Im Dezember habe ich dann Butter bei die Fische getan und zwei Artikel gepostet, in denen es darum ging, wie man automatisiert die Werte von data elements und das Feuern von page load rules testen kann.

Das Thema wird noch weiter behandelt werden, z.B. fehlt noch das Abtesten von event-based rules oder direct call rules.

Hier möchte ich eigentlich heute nur erklären, was das soll. Und das geht in zwei Richtungen:

  • Abgrenzung von Tools wie ObserverPoint oder HubScan, die ja sehr kompetente Testtools für unsere Branche sind, und
  • warum ich denke, dass solche Tests besonders für uns lebenswichtig sind und ein ungeheures Potential mitbringen.

Fangen wir mal mit dem zweiten Teil an, also der Frage nach dem Sinn.

Tests für DEs und PLRs

Warum sollten wir uns für Tests auf diesem Niveau einsetzen? Warum DEs und PLRs testen?

Ich glaube, dass wir alle darunter leiden, dass Development und Webanalyse/Marketing verschiedene Sprachen sprechen. Dass wir besser sein könnten, wenn wir in Projekten als Partner mitreden könnten, von Anfang an.

Ich glaube, dass die Kommunikation an dieser Schnittstelle unser grösstes Problem ist, sowohl was Projekte angeht (neue Site bauen), als auch den täglichen Betrieb.

Ich glaube, dass ein Tag Management System (und prinzipbedingt geht es dann hier immer um DTM) der ideale Platz ist, an dem man die Schnittstelle zwischen Entwicklung und Webanalyse/Marketing definieren kann.

Und ich glaube, dass eine Definition an dieser Schnittstelle helfen würde.

Nutzniesser wären wir, Webanalysten und Marketer. Aufwand betreiben müssten Development und Betrieb. Deswegen sollte der Aufwand so klein sein wie möglich, sprich automatisiert.

Da der Entwicklung in den allermeisten Fällen Funktionalität wichtiger ist als Messung, muss man sich auf ein Minimum einigen, das die Site zur Verfügung stellen muss. Die Definition eines Tests kann solch ein Minimum darstellen.

Zusammengefasst:

Development hat viel zu tun, aber wir möchten gern vermeiden, dass sie unsere Datensammlung kaputtmachen. Also verhandeln wir mit ihnen (oder dem project owner) eine Testsuite. Diese Testsuite testet data elements und page load rules ab, und sie läuft bei jedem Deployment durch, d.h. eine Änderung an der Site, die unsere Messungen stören würde, wird als Fail bei Development erkannt.

Natürlich ist damit nicht sicher, dass nie etwas passiert. Aber es ist besser als heute, ohne Tests.

Und man stelle sich vor, was dabei für uns herauskäme: Die Gewissheit, dass was wir in DTM gebaut haben auch in Zukunft einfach so funktionieren wird. Langfristig! Quasi für immer!

Warum nicht existierende Tools?

Tools wie ObservePoint oder HubScan erfüllen eine ebenso wichtige Aufgabe: Sie geben uns Webanalysten/Marketers ein Gefühl für die Qualität unserer Daten zum jetzigen Zeitpunkt. Das ist bei internen Diskussionen Gold wert!

Ich glaube trotzdem, dass sie nicht ausreichen.

Damit wir langfristig unseren Frieden haben, reicht es nicht aus, dem project owner oder Verantwortlichen für die Site zu sagen, dass die Qualität z.B. von 94% auf 67% gefallen ist. Sein wir ehrlich: Das ist dem manchmal egal, oder es landet auf der Liste der Prioritäten irgendwo hinter wasweissichwas und wird damit erst im Deployment nächsten Herbst geregelt.

Eine Testsuite hingegen ist etwas, mit dem Development lebt. Das kennen die, und darauf können sie schnell reagieren, ohne verstehen zu müssen, was weiter hinten passiert.

Wenn wir Development dazu bekommen, uns die Basis bereitzustellen, dann können wir damit machen, was wir wollen.

Die Basis muss stimmen, alles andere ist nur PowerPoint.

Zukunft auf Deutsch

Das zweite Thema heute hat ebenfalls mit dem anderen Blog zu tun. Wer dieses Blog schon länger verfolgt, wird sich erinnern, wie ich früher häufiger gepostet habe. Aber: Auf dem anderen Blog ist meine Reichweite um ein Vielfaches grösser, und deswegen hat sich das merklich verschoben.

Ich stelle mir seit ein paar Monaten die Frage, ob dieses Blog eigentlich noch sinnvoll ist. Der Traffic dümpelt so vor sich hin, und bei einer Frequenz von einem Artikel pro Monat kann man auch nicht mehr erwarten. Meine Hoffnung, Gastbeiträge zu bekommen, haben sich in den letzten Jahren nicht erfüllt.

[Screenshot]

Key Metrics WebADE

Mir ist klar, dass wir hier oft Anfänge von Diskussionen führen, und dass es nicht wirklich viele deutschsprachige Ressourcen gibt. Mir ist das Blog, das ja als eine Art Verteidigungshandlung an den Start ging, über die Jahre durchaus an’s Herz gewachsen.

Ich habe nur das Gefühl, dass ich nicht genügend Fokus darauf habe(n kann), und ein halbherziges Unterfangen ist ein gescheitertes Unterfangen.

Daher könnte es sein, dass ich dieses Jahr nicht zuende führen werde.

Man wird sehen.

7 Gedanken zu „TDD & Zukunft – auf Deutsch

  1. Till

    Zum zweiten Thema: Für mich hattest Du immer eine Trennung zwischen Analyse für Marketer (hier auf Deutsch) und Entwicklung (drüben auf Englisch). Diese Trennung find ich auch gar nicht so ungeschickt. Die meiste Enticklung passiert nun mal im englischsprachigen Raum. Manch eine Diskussion über Grundsätze lässt sich für uns aber einfach auf Deutsch führen als auf Englisch. In letzter Zeit hast Du scheinbar einfach mehr Freude an der Entwicklung als an grundsätzlichen Themen, aber das kann sich ja auch wieder ändern.

    Sprich, behaltes gerne beide Blogs bei, ich fände es gut.

    Antworten
      1. Till

        Ich komme da vielleicht die Tage mal mit was auf Dich zu. Auch wenn es dann nur ein Tropfen auf den heißen Stein ist (Thema Pipeline)

        Antworten
  2. Bijan S.

    …nur mal schnell zwischen Angel und Tür 😉

    Moin Jan,
    ich verfolge beide Blogs, die Themen zu trennen ist ebenso wenig schlecht wie unterschiedliche Sprachen da (angedachte) unterschiedliche Zielgruppen.

    – A developer’s guide to web analytics
    – Nützliches, Wichtiges und Wissenswertes über Adobe SiteCatalyst und andere Tools

    Im Prinzip also eine hervorragende Idee!

    Aber: Es gibt es immer mal wieder Überschneidungen bzw. zusammenhängende Themen und ich kann mir Deinen Aufwand beides separat zu pflegen und partiell Texte zu wiederholen (im Sinne von ‚den Leser abholen‘) lebhaft vorstellen.

    Frage: Was würdest Du machen, wenn Du heute einen Blog zu den Themen starten wollen würdest?

    Es gibt immer Gründe Dinge auf englisch zu schreiben (besonders wenn sie technisch sind und eben solche Quellen und Ziele (bspw. code) haben), aber auch ebenso viele Gründe und vielleicht einen mehr* für die schöne deutsche Sprache.

    * wer macht das schon auf deutsch und wie ist die sprachliche Verteilung der Zielgruppe? -> deutsch wäre da schon ein Alleinstellungsmerkmal

    Warum nicht eine Plattform mit den Themen die Dir gerade am Herzen liegen und wenn sich daraus ‚mehr‘ ergibt (technisch gestartet und in einem Bogen bis zum anwendungsbezogenen Nutzen geendet), kannst Du es einfacher aufteilen und warum nicht auch sprachlich so wie es sich am besten und verständlichsten darstellen lässt? Und alles unter einem Schirm, ich finde das pragmatischer zur Pflege und auch aus Nutzersicht. Natürlich könntest Du Leser verlieren (einerseits sprachlich, anderseits -vielleicht- aufgrund einseitigerer Interessenlage), aber vielleicht gewinnst Du auch neue?

    Sehr schön auch: ‚Die Basis muss stimmen, alles andere ist nur PowerPoint‘ – ich mag PP nicht und mag zusammenhängende Dinge an einem Ort finden.

    Antworten
    1. Jan Exner

      Ich würde vermutlich heute nicht noch einmal auf Deutsch starten. Primärer Grund: Der Leserkreis ist auf Englisch eine Grössenordnung grösser, und das merkt man.

      Aber: Ich sehe auch das Alleinstellungsmerkmal, und vielleicht auch ein wenig die Schönheit der Sprache. Wie gesagt, keine leichte Entscheidung, und eine die ich noch nicht gefällt habe.

      Antworten
  3. Bijan S.

    Ach so,
    Thema 1 – Ack!

    Wenn man das realisieren könnte, wäre es ein Gewinn für alle. Ich mag das, würde bei uns aber ebenso viele Challenges wie bei Implementierung und Änderung sehen. Außerdem braucht’s für den Betrieb ebenfalls zumindest einen Profi; unabhängig davon, dass das Ergebnis sehr reizvoll und den Aufwand allemal wert ist.

    Bijan

    Antworten
    1. Jan Exner

      Ich wüsste nicht, warum man das nicht realisieren können sollte.

      Fehlt zur Zeit vielleicht ein wenig know-how, aber das machen wir uns eben.

      Antworten

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.