10 things to sabotage your test team


Minuten Lesezeit

August 11, 2016

drei Finger mit gemalten Gesichtern

Sei am 10.10.2024 in Mainz dabei und entfessle Dein Potential als Scrum Master 🚀

Klicke einfach auf den folgenden Link und melde Dich an.

Your test team works too effectively? Are bugs reported in no time? The communication between the testers and developers is perfect? All bug reports make sense? Then it is about time to sabotage the whole thing.

In this blog post, you’ll learn 10 things to sabotage any successful test team so that finally everything gets back to normal…

  1. Eliminate any communication between developers and tester

The best thing you can do is to create some nice silos. Put all the testers in their own room/building/department. It’s even better to move them to a different country with a nice time zone (+/- 9 hours or more). That way you can ensure that the communication between the testers and the developers are effectively handicapped. Next step is to prohibit any communication via phone or chat and only rely on email and snail mail.

  1. Never supply enough testing devices with different configurations

Testers always complain that they do not have enough test equipment. Additionally, they want to have different configurations for their testing devices, e.g. different screen resolutions. But who the hell needs all this stuff? If the developers say, their stuff is running in all scenarios, you can truly take them at their word, right?

  1. Never ever make the original requirements transparent

The last thing a tester wants to see are boring requirements. Explorative testing is all you need to ensure the quality of the product. Requirements only puzzle the simple mind of a tester. They will find out on their own, how the product works.

  1. Inform the test department as late as possible (earliest 2 weeks before the release)

If you give testers to much time to test your product, they will find more bugs which have to be fixed, which will ultimately crush your deadline. We are all on the same page if we say, that nobody is eager to go there, right? So, the best way is to make the testing phase as short as possible. And if you are lucky, there are no testing “resources” available at that short notice, and you can fully rely on the tests the developers did.

  1. Never use dedicated testers

Lately, more and more people are asking for at least one dedicated tester in their teams. But who will pay for this? And to be honest, this little bit of testing can be done easily by the developers alongside their normal work. Developers anyway know best, how to test their stuff.

  1. Allow only manual nonreproducible tests

Reproducible tests lead to reproducible bug requests. It’s always better to just do some wild testing were nobody is able to tell you, what exactly lead to the strange bug they found. This ultimately leads to more difficult bug fixing, and this is exactly what we want.

  1. Never change an already existing test case

Writing tests is an intricate thing. Unfortunately, the software is changing all of the time, which means that you have to adapt those tests. What a waste of time! Instead, it is much easier to deactivate the (automated) test which also has the advantage that there are no more of these bugging error messages on the build server.

  1. Use intern for testing, only!

ISTQB® Certified Tester? Who needs something like that? They are way to expensive and the budget for the QA department is already consumed. It is much cheaper to hire some interns who will click through your software and be easily exchanged every six months. And there is another advantage: interns will never come up with such crazy, newfangled ideas like code reviews and other nonsense.

  1. Never tag any release

Just throw some build over the fence to your testers without knowing the exact version. Never tag or version anything. This makes it way more difficult to write reasonable bug reports. And if they report a bug, a developer can just say: “but it is working on my machine….” So much fun.

  1. Treat testers as incarnated evil, who only want to destroy your product

Testers are evil, who supposedly destroyed stuff already as a toddler. And they want to destroy your product, too. Avoid any contact with them and reduce your communication to a minimum. Refuse any help from them as they will use this knowledge to find even more effective ways to bring your product to its knees. I even heard about secret tester meetups and community of practices. I don’t want to know what is happening there.


If you have some other ideas how to sabotage your test team, let me know in the comments.

About the author 

Marc Löffler

Marc Löffler ist Keynote-Speaker, Autor und Mentor für passionierte Scrum Master. Er befasst sich schon seit 2005 leidenschaftlich mit agilen Methoden, wie z.B. Scrum, Kanban oder eXtreme Programming. Bevor er mit dem Thema Agilität in Berührung gekommen war, hat er als zertifizierter Projektmanager (IPMA) bei Firmen wie Volkswagen, Siemens und EADS erfolgreich multinationale Projekte geleitet. Mit Begeisterung hilft er Unternehmen dabei, agile Werte zu verstehen und genau die Form von Agilität zu finden, die zum jeweiligen Unternehmen passt. Dabei nutzt er sein PASSION Modell, um die jeweilige Situation zu analysieren und sinnvolle nächste Schritte hin zur passionierten, agilen Organisation zu definieren. Er liebt es, neue Einsichten zu generieren, und unterstützt Unternehmen dabei, Probleme aus kreativen, neuen 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. Im Februar 2022 folgte dann das Buch "Die Scrum Master Journey" beim BusinessVillage Verlag.

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 die kostenlose Anleitung für
Deine persönliche