Ich beobachte manchmal, dass Tester irgendwie als Teammitglieder zweiter Klasse behandelt werden. Dieser Eindruck entsteht jedenfalls, wenn man sieht, wie wenig Unterstützung sie von Entwicklern bekommen. Ich meine weniger die Kommunikation (obwohl das manchmal auch sehr relevant ist), als vielmehr die handfeste technische Unterstützung.
Für das Gesamtergebnis zählt ja nicht nur, wie schnell etwas programmiert ist, sondern auch wieviel Zeit wir für die notwendige Qualitätssicherung aufwenden müssen. Hier also in paar Anregungen zu technischen Hilfestellungen für Tester.
Passende Testdaten vorhalten. Das ist der einfachste Weg um das Testen zu erleichtern: einige gut ausgewählte Testdatensätze, die die wichtigsten Regressionsfälle und aktuelle Features abdecken. Natürlich macht das Arbeit, es hilft aber auch sehr dabei, die Aufgabenstellung zu klären, denn Testdaten sind ja realistische Beispiele. Dazu gehört, dass ein Tester das System wieder in einen wohldefinierten Grundzustand zurückversetzen kann. Das sollte möglichst schnell gehen, man kann dafür z.B. mit virtuellen Maschinen arbeiten oder Datenbank-Dumps laden.
Schnell und einfach in einen bestimmten Zustand kommen. Auch Tester wollen meist nur einen bestimmten Ausschnitt eines Arbeitsablaufes testen: Wie kommen wir von A nach B, und ist danach alles so, wie erwartet? Es wird nur sehr mühsam, wenn wir erstmal aufwändig zu Zustand A navigieren müssen. Daher sollte man strategische Abkürzungen für Tester einbauen.
Das kann sein: sich als User XY mit bestimmten Rechten einloggen, mit einem Klick diesem User eine Historie von Transaktionen zuordnen, und ihm einen Mengenrabatt einräumen – ohne dass man erst 10 Minuten in diversen Administrationsinterfaces herumklicken muss.
Bei Workflow-Applikationen kann man dem Tester die Möglichkeit geben, bestimmte zeitraubende Schritte schneller abzuarbeiten oder ganz zu überspringen.
Interna zeigen. Ich habe schon Applikationen gesehen, bei denen ein Tester nicht herausfinden konnte, welche Version mit welchen neuen Features er denn genau vor sich hat. Die Information dazu war irgendwo vergraben; man wusste nur, es war “das Staging-Deployment von Mittwoch”.
Auch eine private Ansicht, die gewisse Details unter der Haube eines Geschäftsobjektes zeigt, kann beim Testen sehr hilfreich sein. Statt sich mühsam durch die Applikation zu klicken, um etwas zu verifizieren, sieht man es auf einen Blick. Auch für komplexere Verweis-Ketten (Artikel -> Warengruppe -> Aktion -> Rabatt) kann man den Testern einfach Hyperlinks anbieten.
Diese Ansichten werden natürlich nur für Tester freigegeben, die echten User bekommen sie nie zu sehen.
Reibungsverluste aller Art vermeiden. Auch beim Testen gilt: Turnaround-Zeiten möglichst kurz halten und ständig reduzieren. Wenn man das Testen eine Weile beobachtet, sieht man alle möglichen unnötigen Reibungsverluste. Oft ist zu einem Ticket nicht genug Kontext aufgeschrieben: Wie testet man denn das Feature, wenn es fertig ist? Der Entwickler hat sich schon sein eigenes Vorgehen dafür zurechtgelegt, da wäre es doch schön, wenn er es dem Tester erklärt.
Ein anderes Beispiel: Von der Applikation versendete Emails sollten nicht mühsam aus einer Inbox gefischt werden müssen, sondern irgendwo zentral in der Applikation (bzw. in der Testumgebung) verfügbar sein.
Es ist kein Hexenwerk. Oft sind es Kleinigkeiten, mit denen man Testern ihre Arbeit wesentlich erleichtern kann. Warum geschieht es dann so selten? Ich vermute, die Tester sind es nicht gewohnt, dass sie auch Anforderungen an die Entwicklung stellen können. Aber selbst wenn die Entwickler ihre eigene Arbeit testen, machen sie sich das Leben manchmal unnötig schwer. Wahrscheinlich denken sie, dass jede Zeile Code nur den Bedürfnissen der Endanwender zu dienen hat. Dabei sollte möglichst einfache Testbarkeit zu den Entwicklungszielen dazugehören, ebenso wie Wartbarkeit und Performance.
Matthias Berth