by marc

Juli 16, 2015

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.

About the author 

marc

Marc Löffler ist selbständiger Agile Coach, Autor und Keynote-Speaker. Er befasst sich leidenschaftlich mit agilen Managementmethoden. Bevor er mit agilen Methoden in Berührung gekommen ist, hat er als zertifizierter Projektmanager bei Firmen wie Volkswagen, Siemens und EADS gearbeitet. Mit Begeisterung hilft er Unternehmen dabei, agile Werte zu verstehen und zu leben. Er liebt es, neue Einsichten zu generieren, und unterstützt Teams dabei, Probleme aus anderen Blickwinkeln zu betrachten. Seit September 2018 ist er zertifizierter Professional Speaker GSA (SHB) mit der besten Keynote seines Jahrgangs. Im Jahr 2014 erschien sein Buch „Retrospektiven in der Praxis“ beim dpunkt.verlag. Im Jahr 2018 folgte das Buch „Improving Agile Retrospectives“ bei Addison Wesley.

Leave a Reply

Your email address will not be published. Required fields are marked

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Hol Dir das kostenlose Poster

Lerne die Voraussetzungen für echtes, agiles Arbeiten kennen!