Dein Testteam arbeitet zu effektiv? Bugs werden nahezu sofort reportet? Die Kommunikation zwischen der Entwicklung und dem Testteam ist perfekt? Alle Bugreports machen Sinn? Dann wird es Zeit das Ganze zu sabotieren. In Blog-Post lernst Du 10 Möglichkeiten kennen, wie Du Dein Testteam erfolgreich sabotieren kannst; damit endlich wieder alles „normal“ läuft.
1. Unterbinde jegliche Kommunikation mit den Entwicklern
Am besten ist es, wenn die ganzen Tester in einem eigenen Raum oder Gebäude sitzen. Noch besser ist es, wenn sie in einer anderen Stadt oder Land mit verschiedenen Zeitzonen arbeiten. So kann man die Kommunikation zwischen Testern und Entwicklern effektiv erschweren. Telefon und Chat gehören auch verboten, so dass die ganze Kommuniktion auf Emails und Briefen basiert. Damit hast Du schonmal den Grundstein für eine erfolgreiche Sabotage gelegt.
2. Stelle nie genügend Geräte mit verschiedenen Konfigurationen zur Verfügung
Die Tester jammern immer, dass sie nicht genug Testequipment haben. Dann wollen sie auch noch verschiedene Konfigurationen, wie z.B. verschiedene Bildschirmauflösungen. Wer braucht sowas schon? Wenn die Entwickler sagen, es läuft auch auf anderen Konfigurationen, dann wird das auch stimmen, oder?
3. Mache auf keinen Fall die ursprünglichen Anforderungen transparent
Das letzte was ein Tester sehen will, sind langweilige Anforderungen. Exploratives Testen ist völlig ausreichend, um die Qualität des Produkts sicher zu stellen. Anforderungen würde nur das einfache Gemüt eines Testers verwirren. Die finden auch so raus, wie das Produkt funktioniert.
4. Informiere die Testabteilung über notwendige Tests frühestens 2 Wochen vor dem finalen Release
Wenn die Tester mehr Zeit zum Testen bekommen, dann finden sie auch mehr Bugs. Und das will doch wirklich niemand, oder? Also verkürzt man die Testzeit auf ein Minimum, so dass die Deadline auch noch eingehalten werden kann. Wenn man Glück hat, sind so kurzfristig keine Ressourcen verfügbar und man kann sich ganz auf die Tests der Entwickler verlassen.
5. Nutze nie dedizierte Tester in den Teams, das kann auch wer nebenher machen
In letzter Zeit werden immer mehr Stimmen laut, dass man mindestens einen dedizierten Tester im Team haben sollte. Wer soll das denn bitte bezahlen? Und überhaupt, das bisschen Testen kann man als Entwickler doch noch prima nebenher machen. Die wissen sowieso am besten, wie sie ihre Software testen müssen.
6. Erlaube ausschließlich manuelle, nicht reproduzierbar Tests
Reproduzierbar Tests führen zu nachvollziehbaren Bug-Requests. Viel besser sind also irgendwelche wilden Tests, bei dem niemand mehr sagen kann, was man genau gemacht hat, um einen Fehler zu provozieren. Das erschwert wiederum die Fehlersuche, was genau das ist, was wir wollen.
7. Passe vorhandene Tests niemals wieder an
Tests zu schreiben ist eine aufwendige Sache. Dummerweise ändert sich die Software andauernd und die Tests müssen angepasst werden. Völlige Zeitverschwendung! Stattdessen kann man die (automatischen) Tests doch prima deaktivieren, dann kommen auch nicht dauernd die nervenden Fehlermeldungen vom Build Server.
8. Nutze ausschließlich Praktikanten zum Testen
ISTQB® zertifizierte Tester? Wer braucht denn sowas? Die sind viel zu teuer und das Budget für die QA Abteilung ist sowieso schon hoffnungslos überzogen. Viel günstiger sind Praktikanten, welche sich durch die Software klicken und alle 6 Monate ausgetauscht werden. Die kommen auch nicht mir irgendwelchen neumodischen Ideen wie Code-Reviews oder anderem unnötigem Quatsch.
9. Tagge niemals einen Release
Wirf einfach irgendeinen Build vom Build Server über den Zaun, ohne zu wissen um welchen Stand es sich genau handelt. Das macht es den Testern umso schwerer vernünftige Bug-Requests zu schreiben. Und wenn sie einen Fehler melden, kann man als Entwickler immer den wunderschönen Satz rauskramen: „Bei mir läuft’s aber“.
10. Behandle Tester wie das personifizierte Böse, die nur dein Produkt kaputt machen wollen
Tester sind böse Menschen, die vermutlich schon als Kleinkinder alles immer nur kaputt gemacht haben. Und die wollen jetzt auch DEIN Produkt zerstören. Vermeide jeden Kontakt mit ihnen und reduziere die Kommunikation auf ein Minimum. Lehne jede Hilfe von ihnen ab, da sie deine Informationen nur nutzen werden, um dein Produkt noch effektiver in die Knie zu zwingen. Es soll sogar geheime Tester-Treffen geben. Was bei diesen Treffen passiert, will ich wirklich nicht wissen…
Fallen Dir noch mehr Dinge ein? Dann schreib sie in die Kommentare. An dieser Stelle möchte ich Judith Islitzer für ihre Unterstützung beim Brainstorming danken.
Hier sind auch noch die Folien zu meinem Vortrag auf dem German Testing Day 2015.
