Als allgemeine Regel gilt: Egal, wie hoch Ihre Testabdeckung ausfällt, sie ist es nicht. Egal, wie viel der bekannten Oberfläche Sie abdecken, es wird eine spannende Reihe von Dingen geben, von denen Sie nicht wussten, dass Sie sie testen müssen. Analytics fiel für uns in diese Kategorie.

Wir verwenden Google Analytics in unserer Webanwendung, um ein Gefühl dafür zu bekommen, wie Benutzer das Produkt verwenden. Zuletzt haben wir ermittelt, welche Funktionalität für die Mobile Seite . Ich schaue mir also im Allgemeinen jede Woche oder alle zwei Wochen unsere Analysen an, um den Entwicklern zu helfen. Als Simon mich fragte, wie beliebt die mobile Website sei, war ich mir ziemlich sicher, dass die Antwort nicht „Die Nutzung unserer Webanwendung hat um 98 % abgenommen“ lautete:

Ich werde keine Namen nennen, aber der Täter reimt sich auf „itwasian“.

Was kaputt ging

Unsere Benutzeroberfläche besteht fast ausschließlich aus HAML unterstützt durch backbone.js, oft gleichzeitig . Das bedeutete, dass wir den Standardcode von Google Analytics überarbeitet haben:

 :javascript var gaJsHost = (('https:' == document.location.protocol) ? 'https://ssl.' : 'http://www.'); document.write(unescape('%3Cscript src='' + gaJsHost + 'google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E')); :javascript // 

Sie werden feststellen, dass dadurch zwei JavaScript-Blöcke generiert werden, die wir hilfreicherweise zu einem zusammengeführt haben.

Das hat alles kaputt gemacht – und mit „alles“ meine ich einige mobile und seltene Browser, die den Code trotzdem wie vorgesehen ausgeführt haben. Für 98 % unserer Besucher bedeutet die Tatsache, dass wir diese beiden Skriptblöcke zusammengeführt haben, dass der DOM nach document.write keine Kontrolle mehr erhält und das Laden von ga.js nicht erfolgt, bevor auf _gat verwiesen wird. _gat existiert nicht und das ist das Ende unserer Analysen auf dieser Seite.

Die einfache Lösung besteht natürlich darin, den zweiten Skriptblock wieder einzufügen. Stattdessen sind wir jedoch zum neuesten asynchronen Google Analytics-Code übergegangen, der keine zwei Blöcke benötigt, da er nur erfordert, dass _gaq ein JavaScript-Objekt ist. Der Rest der Funktionalität kommt später, wenn der Browser dazu kommt.

 :javascript var _gaq = _gaq || []; _gaq.push(['_setAccount', 'UA-8759953-1']); _gaq.push(['_setDomainName', 'pagerduty.com']); _gaq.push(['_trackPageview']); (Funktion() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s); })(); 

Testen, ob Google Analytics funktioniert

Um sicherzustellen, dass ich dies in Zukunft früher bemerke, habe ich in unserer Anwendung und auf der Website in Google Analytics einige intelligente Ereignisse eingerichtet, um festzustellen, ob wir ungewöhnlich wenige oder viele Besucher haben.

Es dauert mindestens einen Tag, bis die E-Mail verschickt wird. Das ist schade (ich habe die letzte erhalten, als ich dies geschrieben habe), aber es ist eine weitere Ebene in unserem Warnnetz. Melden Sie sich bei Ihrem Google Analytics-Konto an und Sie sehen „Intelligence Events“:

Ich beabsichtige, später einige fortgeschrittenere Heuristiken einzurichten, aber jetzt testen wir einfach, ob die Analyse funktioniert:

Dieser Tag mit Verzögerung hatte für den Test den Vorteil, dass mir die Warnmeldung von gestern gesendet wurde, als unsere Analyse noch fehlerhaft war (aber ich greife wirklich vor, das als Vorteil zu bezeichnen).

Alles mit PagerDuty verknüpfen

Das ist nicht die Art von Alarm, für die ich mitten in der Nacht geweckt werden möchte, aber ich verwende PagerDuty trotzdem als Vorfallmanagementsystem für meine Analysealarme, teilweise für das Dogfooding, aber auch, um unsere Medienerwähnungen, Twitter-Erwähnungen usw. zu verfolgen.

Zu diesem Zweck habe ich einen Dienst eingerichtet, der Bestätigungen nicht automatisch auflöst oder ablaufen lässt, um alle E-Mails an „analyze-me@pdt-dave.pagerduty.com“ zu verfolgen.

Testen Sie alles

Also fülle ich jetzt unsere Nebelbugz mit neuen Dingen zum Testen:

• Unsere T-Shirt Mailings
• ob wir schnell genug auf Kundenanfragen reagieren
• Testen unserer Ladezeiten auf der Website, im App-Stack, im Blog und auf der Support-Site (auch hier mit automatischen Benachrichtigungen von Google). Wir testen dies bereits mit Neues Relikt .

Ich habe kein gutes Verfahren, um festzustellen, was wir zu testen vergessen, aber ich habe ein paar Grundsätze:

• Wenn es einmal fehlschlägt, wird es für immer getestet. Ich erwarte, dass dies im Durcheinander verloren geht, aber anscheinend haben wir ein oder zwei Leuten, denen ich sie versprochen hatte, nie T-Shirts geschickt, also wurde das automatisiert und ich habe jetzt einen Ad-hoc-Bericht darüber, wer seine Shirts erhalten hat und wer nicht. Wenn es hart auf hart kommt, werde ich es vielleicht in die USPS-Sendungsverfolgung integrieren.
• Es muss automatisch erfolgen und Ihnen idealerweise eine Warnung senden, wenn eine Messung außerhalb des Rahmens liegt. Wir verfolgen unsere Zeit bis zur Lösung mit Zendesk, daher besteht eines meiner Projekte darin, unsere Metriken mit zu automatisieren Automatisierungen
• Seien Sie ein Idiot. Ich teste die Arbeit anderer Leute und versuche, sie zum Scheitern zu bringen. Es ist mir egal, was die Kennzahlen des Zuverlässigkeitsteams sagen, wenn meine Seitenladezeit in die Höhe schießt, verlange ich Antworten.

Wir sind noch ein junges Unternehmen, legen aber großen Wert auf Verfügbarkeit und bei der Arbeit mit Fehlern gibt es bekannte Unbekannte und unbekannte Unbekannte – und als ich hier anfing, hätte ich nie gedacht, wie viel Spaß es mir machen würde, mit Nerf-Pistolen durchs Büro zu schießen, wenn die durchschnittliche Seitenladezeit zunimmt.

(Mit etwas Glück ist dies der erste Beitrag in einer Reihe darüber, was passiert, wenn Sie Ihr Marketing von einem Mathematiker durchführen lassen.)