Von Manuel Brückmann | Tipps | 7 Reaktionen

5 Tipps für Testing – die jeder Conversion Engineer kennen sollte

Das Testen von Verbesserungen im eCommerce hat nicht nur wissenschaftlichen Charakter, sondern auch den praktischen Nutzen, dass Änderungen validiert werden können bevor Sie einem breiten Kundenspektrum präsentiert werden. Der Erfolg einer Änderung lässt sich also schon im Vorfeld prüfen. Demnach bewegt sich der Conversion Engineer sehr viel im Testing-Umfeld. Die folgenden 5 Tipps beschränken sich zwar nicht nur auf Testing, spielen aber hier eine große Rolle.


Conversion Engineer

Kurzer Exkurs – Was ist überhaupt ein Conversion Engineer?

Wie im Artikel der „IEEE Internet Computer Society“ sehr gut beschrieben unterscheidet sich der Engineer vom Developer per se durch völlig unterschiedliche Grundsätze:

Die Vorgehensweise eines Engineers ist eher systematisch, diszipliniert, quantifiziert und basiert dabei auf wissenschaftlichen Ansätzen.

Die Tätigkeit eines Developers dagegen basiert nicht auf Metriken oder wissenschaftlichen Grundsätzen – weshalb der Erfolg der Entwicklung eher Zufall ist.

Mit anderen Worten, die Tätigkeitsweise eines Conversion Engineers basiert auf für die Conversionrate relevanten Faktoren – wie beispielsweise wissenschaftliche Hypothesen – während sich der Web Developer ausschließlich mit der Umsetzung auseinandersetzt, ohne dabei den entsprechenden Rahmen und Hintergrund zu kennen.

Soweit zur Definition und was beide Welten trennt. Was sie gemeinsam haben sind ihre Werkzeuge. Jedoch bewegt sich der Conversion Engineer noch mehr im Frontend als der Web Developer – hat also mehr mit JavaScript, HTML und CSS zu tun. Die Grundfähigkeiten sind jedoch identisch.

Was macht also jetzt einen echten Conversion Engineer aus?

Grundsätzlich gilt: Performance is King – das ist eigentlich nichts Neues. Wir wissen, dass z.B. die Lade- und Reaktionszeit eines Onlineshops Einfluss auf die Conversionrate haben – aber in Bezug auf Testing ist hier die Baustelle eine andere.

Ein guter Entwickler will immer sauberen, validen Code erzeugen, welcher allen Anforderungen der W3C entspricht. Soweit so gut. Sollen bei einem bestehenden eCommerce System Änderungen getestet werden, ohne das schwerwiegendere Eingriffe in die Templates vollzogen werden müssen, so kommt man hier nur mit JavaScript-Manipulation, HTML-Injection und CSS-Anpassungen weiter.

Hier ist der Punkt, an dem der „ordentliche“ Entwickler aufpassen muss. Das Ladeverhalten der Seite darf nicht massiv verschlechtert werden (die Begrifflichkeit „massiv“ deshalb, weil ganz ohne Verzögerung geht es bei <tag>-basierten Systemen nicht). Je länger das Laden des Tests und die Ausführung der Manipulationen dauert, desto größer wird die User Experience negativ beeinflusst. Z.B. wird die Seite subjektiv als langsam empfunden, weil sich Inhalte umbauen und die fertige Seite erst sehr spät zur Verfügung steht. Mit den folgenden Tipps lassen sich die gröbsten Fallen vermeiden:

 

1. Weniger ist mehr

Je weniger Zeichen der manipulierende Code verbraucht, desto besser. Klingt banal, ist aber in der Praxis nicht ganz einfach. Der Gebrauch von Variablen und Methoden sollte stets den schmalen Grat treffen zwischen

  • zu wenig Variablen, die den Code schwer lesbar machen und
  • zu vielen welche zwar „sauber“ aber eine große Dateigröße zur Folge haben

Generell sollten Redundanzen vermieden werden. Überall dort, wo z.B. ähnliche Manipulationen an verschiedenen Elementen durchgeführt werden sollen, bietet es sich natürlich an diese zu Kapseln und in Methoden auszulagern.

Übrigens lassen sich auch JavaScript und CSS für die Testumsetzung sehr gut z.B. mit dem YUI Compressor minimieren.

 

2. JavaScript Performance

In der Regel wird JavaScript – häufig durch die jQuery-Bibliothek – zur Manipulation von Inhalten (z.B. HTML-Injection) genutzt. Hier gilt es insbesondere die richtige Wahl der Selektoren und Variablen zu treffen. Z.B. sollten schwer zu findende Elemente, welche beispielsweise keinen klaren Indikator haben und nur durch Iteration des Dokumentenbaums (DOM) identifiziert werden können, für eine spätere Verwendung in einer Variable zwischengespeichert werden, damit dieser Vorgang nur einmal ausgeführt werden muss.

Klar zu identifizierende Elemente sollten dagegen direkt angesprochen werden (z.B. über #ID). Letzteres hat gerade bei älteren Browsern den Vorteil, dass diese aufgrund mangelnder Selektoren die #IDs deutlich schneller zur Verfügung stellen als – durch die JavaScript Bibliothek selbst – nur durch Iteration zu erreichende Elemente (z.B. CSS-Klassen).

Bei der Manipulation von Inhalten sollte abgewägt werden, wann ein Replacement beispielsweise durch Regular Expressions durchzuführen, und wann es besser ist einfach den Text komplett zu ersetzen. Auch hier spielt die Rendertime – also die JavaScript Performance – des Browsers eine große Rolle. Generell gilt es das 1×1 der JavaScript – Schule zu beachten, z.B. dass String-Vergleiche immer deutlich langsamer sind als Index-Abfragen usw.

 

3. Mehr CSS, weniger JavaScript

Hier findet für den „ordentlichen“ Entwickler der größte Bruch statt. Sollen beispielsweise Elemente im Quellcode verschoben werden, so wäre der sauberste Ansatz sich per JavaScript diese zu holen und sie an gewünschter Stelle einzufügen. Der Code wäre damit auch nach der Manipulation vom Markup sauber.

Dies gilt nicht für Testing – aus mehreren Gründen:

JavaScript Manipulationen sind immer an ein Event gebunden – meistens „on document ready“ also die Dokumentenstruktur (DOM) muss geladen sein. Dies passiert leider oft viel zu spät, je nach dem an welcher Stelle der Code des Tests im Dokument ausgeführt wird hat der Nutzer schon einen Teil des „alten“ Inhalts gesehen – die UX ist beeinflusst.

Dazu kommt, dass es für Suchmaschinen und Validatoren keine Rolle spielt, wie „sauber“ das Markup ist – denn diese bekommen die Testumsetzung nie zu Gesicht.

Die Lösung ist CSS – welches sofort zur Verfügung steht wenn es dem Dokument hinzugefügt wurde. Der Trick ist somit anstatt per JavaScript, die Manipulationen direkt per CSS durchzuführen – soweit möglich versteht sich. Es mag unsauber sein, und einem ordentlichen Entwickler falsch vorkommen, aber z.B.

  • das absolute (um)positionieren von Elementen,
  • dafür Platz schaffen durch paddings und margins,
  • direktes Ausblenden von unnötigen Elementen oder
  • Ergänzen von Textbausteinen (z.B. CSS Pseudo-Klassen)

ist im Ergebnis – und das ist worauf es letztendlich beim Testing ankommt – deutlich effizienter.

 

4. Reduktion von Assets

Jede Grafik, welche im Rahmen einer Test-Variante nachgeladen werden muss, verzögert zusätzlich das Laden der Seite. Auch das hat natürlich sowohl einen physikalischen Einfluss auf die Ladezeit als auch auf die Wahrnehmung – also das gefühlte Fertigladen der Seite.

Die Verwendung von Grafik-Sprites ist hier – analog zur gängigen Website Performance Optimierung – absolut obligatorisch. Auch die Verwendung von CSS3 anstelle von Grafiken ist sehr empfehlenswert, da hier sehr viel an Material gespart werden kann.

 

5. User Experience

Einen weiterer Einflussfaktor auf die Wahrnehmung hat das Ergänzen von Elementen. Nicht immer können bestehende Inhalte angepasst werden, auch neue Elemente müssen gegebenenfalls erzeugt werden.

Dies geht ausnahmslos per JavaScript, was das bereits angesprochene Störgefühl erzeugen kann. Hier bieten sich gängige Methoden aus der User Experience an, z.B. Elemente „weich“ per Fading einzublenden, anstatt sie „hart“ hinzuzufügen.

Oft macht auch die Kombination aus CSS und JavaScript Sinn, so dass beispielsweise der Raum für die Ergänzung bereits per CSS geschaffen wurde, und JavaScript letztendlich nur noch für das Einfügen zuständig ist.

Dadurch wird zum einen nicht nur die Test-Situation verschleiert, auch das gefühlte „umbauen“ der Seite wird gemindert.

 

Worauf sollte noch geachtet werden?

Bei den beschriebenen 5 Tipps gilt es natürlich eins nicht zu vergessen – die CrossBrowser Kompatibilität. Gerade die Anpassungen per CSS oder die Reduktion der Assets machen in alten Browsern Probleme. Auch die JavaScript Rendertime – gerade bei komplexeren Anpassungen oder rudimentären Markup – stellen ältere Browser mit veralteten Rendering-Engines vor Probleme.

Es gilt also einen Blick in die Webanalyse Zahlen zu werfen, um abzuwägen, wie weit man bei der CrossBrowser Kompatibilität zurück gehen muss. Sind die Prozentzahlen niedrig, ist es oft wirtschaftlicher, den alten Browser vom Test auszuschließen, anstatt eine umfangreichere Anpassung und damit gegebenenfalls Verschlechterung der Performance für neuere Browser in Kauf zu nehmen.
Die Erfahrung zeigt, dass mit Ausnahme des B2B-Marktes die Verteilung der Browser mit entsprechenden Fähigkeiten die veralteten Browser deutlich überwiegen.

Fazit:

Nicht nur die Dateigröße der Testinhalte sondern auch der Umfang der Maßnahmen, z.B. die JavaScript Rendertime des Browsers, haben einen Einfluss auf die Testperformance. Das Ziel ist dem Testteilnehmer nicht das Gefühl zu vermitteln, Versuchskaninchen im Labor zu sein, sondern die Website im Originalzustand zu besuchen. Nur wenn die Testsituation neutral ist – kann auch von validen Zahlen und einem fairen Test ausgegangen werden.

Zum Schluss noch ein Hinweis in eigener Sache

Sie kannten schon alle 5 Tipps oder fanden diese zumindest spannend? Sehr gut, wir suchen zur Zeit nach Conversion Engineers, um unser Team aus Conversion Consultants, Architects und Designern aufzustocken.

Neben dem Standort in Bad Homburg haben wir noch Stellen in Hamburg und München zu besetzen.

Wenden Sie sich einfach an karriere@web-arts.com oder www.web-arts.com/karriere. Stichwort „Konversionskraft“ bei der Kontaktaufnahme nicht vergessen.

Manuel Brückmann

Manuel Brückmann ist als Mitglied der Geschäftsleitung bei konversionsKRAFT für den Bereich Technologie verantwortlich. Er beschäftigt sich neben der Beratung im Bereich Testing mit eCommerce-Entwicklung und -Optimierung.
Frage zum Artikel? Frag den Autor

7 Reaktionen auf „5 Tipps für Testing – die jeder Conversion Engineer kennen sollte

  1. Danke für den Artikel.

    Wieder „Futter“ zum verarbeiten.

    Gruß,
    Michael

    • Mit Blick auf Besucherstatistiken frage ich mich, ob die Verwendung von JavaScript tatsächlich sein muß? Ein nicht unbeträchtlicher Anteil von Besuchern unserer Seite hat JS deaktiviert. Daher kann ich nur empfehlen, die VErwendung von JS weitestgehend zu vermeiden.

      • von Manuel Brückmann

        Hallo Herr Fuchs,
        danke für Ihr Feedback. Grundsätzlich stimme ich Ihnen zu. Sofern Ihre Kunden tatsächlich in einer signifikaten Größe JavaScript deaktiviert haben, sollte möglichst auf dessen Verwendung verzichtet werden – zumindest was die Kernfunktionen angeht.
        Allerdings ist dies – so unserer Erfahrung nach – eher die Ausnahme. Kunden haben heut zu Tage (Dank moderner Browser) in der Regel JavaScript aktiviert. Dies zeigt auch die aktuelle Webhits-Statistik (http://www.webhits.de/deutsch/index.shtml?webstats.html) bei der rund 94% aller Nutzer JavaScript aktiviert haben.
        Der Artikel bezog sich weniger auf Shops allgemein, sondern eher auf Testing innerhalb von eCommerce Systemen. Mit wenigen Ausnahmen ist dort Testing ausschließlich durch JavaScript möglich. Hat ein Nutzer JavaScript deaktiviert, nimmt er nicht am Test teil. Auch die Performance-Tipps sind eher in diesem Kontext zu sehen. Nur im Testingumfeld sollte z.B. durch CSS die Verwendung von DOM-Manipulation durch JavaScript umgangen werden (aufgrund des beschriebenen Szenarios). Überall dort, wo ein sauberes Markup notwendig ist (z.B. für SEO) sollte dies beibehalten werden.

        Schreibe einen Kommentar

        Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.