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…
- 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.
- 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?
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
