SurveyTester prüft jede aufgenommene Seite automatisch: Rechtschreibung, defekte Bilder, sichtbares HTML, nicht aufgelöste Pipe-Ins, leere Antwortlisten, fehlende Rotation und mehr - insgesamt 26 Prüfungen. Was eine Prüfung meldet, ist ein Fund. Eine Person nimmt den Fund an, und er wird zu einem Issue in deiner Issue-Liste - mit den Klassifizierungswerten, die du hier festlegst. So landet er im richtigen Status, mit der richtigen Schwere, bei der richtigen Person.
Dieser Artikel richtet sich an Administratoren. Er führt durch die drei Entscheidungen hinter einer guten Einrichtung: welche Prüfungen deine Firma laufen lässt, welche Projekttypen davon abweichen und welche Klassifizierungswerte die Issues jeder Prüfung bekommen. Was jede Prüfung findet, steht in Auto-Detect Issues.
Wie die Einstellungen zusammenspielen
Die Prüfungen werden auf drei Ebenen geschaltet. Jede Ebene erbt von der darüber und kann sie überschreiben:
| Ebene | Wo | Typischer Einsatz |
|---|---|---|
| Firma | Administration › Unternehmenseinstellungen › Automatische Fehler-Erkennung | Der Standard für jedes Projekt der Firma |
| Projekttyp | Administration › Klassifizierungsfelder › Projekttyp auswählen › Einstellungen für automatische Ticket-Erkennung | Abweichungen für eine Art von Projekt und die Klassifizierungswerte umgewandelter Funde |
| Projekt | Projektdefinition › Allgemein › Automatische Ticket-Erkennung | Eine Prüfung, die für eine bestimmte Umfrage keinen Sinn ergibt |
Die Klassifizierungswerte für umgewandelte Funde werden nur pro Projekttyp festgelegt, weil die Klassifizierungsfelder selbst zum Projekttyp gehören.
Schritt 1: Festlegen, welche Prüfungen deine Firma laufen lässt
Nicht jede Prüfung passt zu jeder Firma. Geh die Liste einmal mit den Leuten durch, die Umfragen testen und korrigieren, und schalte die Prüfungen unter Administration › Unternehmenseinstellungen › Automatische Fehler-Erkennung ein oder aus. Hilfreich ist es, die Prüfungen in drei Gruppen zu sortieren:
| Gruppe | Prüfungen | Empfehlung |
|---|---|---|
| Defekte Umfrage - Probleme, die ein Befragter sofort sieht | Umfragefehler auf Seite erkennen, Fehlende Bilder erkennen, Sichtbares HTML auf der Seite erkennen, Nicht aufgelöste Pipe-Ins erkennen, Matrixfragen ohne Attribute erkennen, Kategorische Fragen ohne Kategorien erkennen, Einzelantwortfragen mit nur einer Kategorie erkennen, Leere Kategorien erkennen, Leere Attribute erkennen | Für jede Firma an. Diese Funde sind fast immer echte Probleme |
| Textqualität und Einheitlichkeit | Rechtschreibprüfung, Falsche Sprachteile erkennen, Marken erkennen, die in der Testsprache unbekannt sind, Kategorie-Taxonomie prüfen, Attribut-Taxonomie prüfen, Doppelte Kategorien erkennen, Doppelte Attribute erkennen, Fehler in numerischen Kategorie-Bereichen erkennen, Fehler in numerischen Attribut-Bereichen erkennen, Uneinheitliche Bereichs-Trennzeichen erkennen, Kategorien / Attribute / Fragen mit Unterstrich im sichtbaren Label erkennen | An, wo Textqualität Teil eurer QA ist. Die Rechtschreibprüfung funktioniert am besten mit einem gepflegten Firmenwörterbuch; die Unterstrich-Prüfungen können viele Funde liefern, wenn eure Umfrageplattform technische Namen absichtlich zeigt |
| Umfragedesign über viele Testläufe | Fehlende Rotation erkennen, MaxDiff-Balance prüfen, Item-Anzeige prüfen, Von einer früheren Frage abhängige Einträge prüfen | An, wenn eure Projekte Rotation, MaxDiff oder lange Teilmengen-Listen nutzen. Diese Prüfungen beurteilen viele Testläufe gemeinsam und brauchen SurveyBots für genug Belege |
Eine ausgeschaltete Prüfung kostet nichts, und du kannst sie jederzeit wieder einschalten. Fang mit weniger Prüfungen an und nimm weitere dazu, wenn dein Team den Umgang mit Funden gewohnt ist - eine Flut von Funden, die niemand prüft, hilft niemandem.
Schritt 2: Die Prüfungen pro Projekttyp anpassen
Projekttypen stehen für Arten von Projekten - zum Beispiel Ad-hoc-Studie, Tracker-Welle oder Übersetzungsprüfung - und brauchen oft unterschiedliche Prüfungen. Öffne Administration › Klassifizierungsfelder, wähle den Projekttyp und wechsle in die Ansicht Einstellungen für automatische Ticket-Erkennung.
Die Tabelle hat eine Zeile pro Prüfung:
- Aktiviert zeigt, ob die Prüfung für Projekte dieses Typs läuft. Sie startet mit dem Firmenstandard.
- Ein Klick auf das Kästchen weicht vom Firmenstandard ab. Die Zeile zeigt dann das Kennzeichen Projekttyp-Anpassung. Ein Klick auf das Kennzeichen kehrt zum Firmenstandard zurück.
- Die Spalte Automatische Prüfung nennt die Prüfung und erklärt, was sie findet.
Typische Abweichungen:
- Eine Tracker-Welle, die eine bereits gründlich getestete Umfrage wiederholt: nur die Gruppe defekte Umfrage, damit die Tester nicht in jeder Welle mit denselben Text-Funden überflutet werden.
- Eine Übersetzungsprüfung: Rechtschreibprüfung, falsche Sprachteile und Marken in der Testsprache an, die Design-Prüfungen aus.
- Ein Konzepttest mit MaxDiff: MaxDiff-Balance an, auch wenn sie auf Firmenebene aus ist.
Schritt 3: Die Klassifizierungswerte für jede Prüfung wählen
Rechts neben den Prüfungen zeigt die Tabelle eine Spalte für jedes Klassifizierungsfeld des Projekttyps, das Werte zur Auswahl hat - zum Beispiel Status, Schwere, Kategorie oder Zuständig. Wähle für jede Prüfung den Wert, den ein Issue bekommt, wenn ein Fund dieser Prüfung umgewandelt wird. Die Auswahl wird sofort gespeichert.
Denk dabei daran, wie dein Team Issues heute verteilt:
| Prüfung (Beispiele) | Status | Schwere | Kategorie | Zuständig |
|---|---|---|---|---|
| Umfragefehler auf Seite erkennen, Fehlende Bilder erkennen, Nicht aufgelöste Pipe-Ins erkennen | Neu | Hoch | Programmierung | Skriptprogrammierer |
| Rechtschreibprüfung, Falsche Sprachteile erkennen | Neu | Niedrig | Text / Übersetzung | Übersetzer |
| Kategorie-Taxonomie prüfen, Doppelte Kategorien erkennen | Neu | Mittel | Text | Skriptprogrammierer |
| Fehlende Rotation erkennen, MaxDiff-Balance prüfen, Item-Anzeige prüfen | Neu | Hoch | Programmierung | Skriptprogrammierer |
Die Feldnamen und Werte oben sind Beispiele - nimm die Klassifizierungsfelder, die dein Projekttyp tatsächlich hat (siehe Classification Fields). Drei Regeln halten den Ablauf sauber:
- Immer einen offenen Status zuordnen. Ein Feld ohne Zuordnung bleibt am umgewandelten Issue leer - der Standardwert des Felds wird nicht eingetragen. Ein Issue ohne Status fällt aus jeder Liste und jedem Filter, die auf dem Status beruhen.
- Nie einen schließenden Wert oder einen Wert zur Nachprüfung zuordnen. Ein Wert mit angehaktem Problem schließen würde das Issue im Moment seiner Entstehung schließen; ein Wert mit angehaktem Erneut prüfen würde es direkt in die automatische Nachprüfung schicken. Umgewandelte Funde müssen als offene Issues starten.
- Die Felder zuordnen, nach denen dein Team filtert. Arbeiten Tester und Skriptprogrammierer mit Listen, die nach Kategorie oder zuständiger Person gefiltert sind, müssen die umgewandelten Issues diese Werte tragen, sonst sieht sie niemand.
Schritt 4: Festlegen, wer mit Funden arbeitet
Funde nützen nur, wenn jemand sie prüft. Vier Berechtigungen unter Administration › Rollen, Bereich Issues, legen fest, wer das tut:
| Berechtigung | Was sie erlaubt |
|---|---|
| Kann automatisch erkannte Probleme im Backend verwalten | Funde im Fund-Dialog der Seite Tickets prüfen und in Issues umwandeln |
| Kann automatisch erkannte Probleme während des Testens verwalten | Funde direkt beim Testen in der Browser-Erweiterung annehmen oder ablehnen |
| Automatisch erkannte Probleme standardmäßig anzeigen | Umgewandelte Funde in der Issue-Liste anzeigen, ohne zuerst den Filter einzuschalten |
| Kann automatisch erkannte Probleme löschen | Offene oder abgelehnte Funde endgültig löschen |
Gib die ersten beiden den Leuten, die entscheiden, was ein echtes Problem ist - meist QA - und die dritte allen, die Issues beheben. Siehe Roles and permissions.
Schritt 5: Das Ergebnis in einem Projekt prüfen
Lege ein Testprojekt mit dem Projekttyp an, starte einen Test und öffne die Funde auf der Seite Tickets. Wandle von jeder Art, die du zugeordnet hast, einen Fund um und öffne die neuen Issues: Jedes sollte den Status, die Schwere und die anderen gewählten Werte tragen. Fehlt ein Wert, hat das Feld für diese Prüfung noch keine Zuordnung.
Braucht ein bestimmtes Projekt eine Prüfung nicht, schalte sie unter Projektdefinition › Allgemein › Automatische Ticket-Erkennung aus - der Projekttyp bleibt davon unberührt.
Gut zu wissen
- Änderungen gelten ab jetzt. Eine eingeschaltete Seitenprüfung sieht sich die Seiten an, die ab dann aufgenommen werden, nicht bereits ausgewertete Testläufe. Die Design-Prüfungen (Rotation, MaxDiff, Item-Anzeige, abhängige Einträge) beurteilen beim nächsten Projekt-Scan alle Testläufe des Projekts. Früher umgewandelte Issues behalten ihre Werte.
- Nur Felder mit Werten erscheinen als Spalten. Freitextfelder lassen sich nicht zuordnen.
- Die Zuordnung gehört zum Projekttyp. Eine Firma mit mehreren Projekttypen legt die Werte für jeden davon fest; die Firmenebene entscheidet nur, welche Prüfungen laufen.
- Nachprüfungen hängen an den Prüfungen. Ein behobenes Issue, das aus einem Fund entstand, wird nachgeprüft, indem dieselbe Prüfung erneut läuft. Schaltest du eine Prüfung für ein Projekt aus, warten ihre Nachprüfungen, bis sie wieder eingeschaltet ist.
Das Wichtigste
Drei Entscheidungen lassen die automatische Erkennung für dein Team arbeiten: welche Prüfungen standardmäßig laufen, wo ein Projekttyp etwas anderes braucht und welche Klassifizierungswerte die Issues jeder Prüfung bekommen. Leg sie einmal pro Projekttyp fest, und jeder Fund, den deine Tester annehmen, kommt als Issue an, das bereits einsortiert, priorisiert und zugewiesen ist.