18 Ways to Undermine a Testing Team

Based on practical experience, the article lists eighteen measures that can be used to deliberately cripple a testing team, offering insights that may inspire readers about the consequences of mismanagement.

QA (Quality Assurance)

1. Make QA solely responsible for all online incidents: Immediately question testers when bugs appear, involve product, development, and operations, and publicly blame the QA lead in company groups.

2. Define as many metrics as possible: Track defect rejection rates, bug discovery ratios, and test‑person defect counts, using any metric without clear purpose to pressure the team.

Project Manager

3. Compress testing time aggressively: Push testing cycles from three days to one, or even half a day, demanding overtime and treating any delay as unacceptable.

Product Manager

4. Make requirements intentionally low‑quality: Keep documentation vague, use large‑granularity features, introduce logical conflicts, and avoid involving testers in reviews.

5. Encourage frequent requirement changes: Treat constant change as a virtue, even if it burdens the development team.

6. Skip formal acceptance: Treat product acceptance as a formality, relying on testers to catch any issues after release.

Developers

7. Multiply branches endlessly: Adopt a "branch‑is‑king" mindset, merging frequently and forcing testers to validate every branch.

8. Refuse to discuss testability: Claim that only testers should worry about testability, not developers.

9. Skip self‑testing: Assume code is fine if it compiles locally, leaving verification entirely to QA.

10. Avoid design reviews: Dismiss the need for reviewing technical solutions, arguing they are only for developers.

11. Omit defect comments: Change bug status to "Ready for verification" without any explanatory notes.

Testers

12. Become developers' shadow: Follow developers' instructions blindly, perform low‑level tasks like flashing devices, capturing logs, and data extraction.

13. Ignore implementation details: Focus solely on black‑box validation, refusing to understand the underlying code.

14. Downplay process standards: Treat extensive testing procedures as optional and rarely followed.

15. Prioritize automation above all: Claim that only automation skills matter for testing excellence.

16. Dismiss continuous learning: Argue that on‑the‑job experience outweighs formal education or reading.

Organizational Culture

17. Promote excessive overtime: Use high work saturation as a performance metric, scheduling work into evenings and weekends.

18. Pursue "de‑testing": Treat testing as a cost center to be eliminated, shifting remaining testing responsibilities onto developers.

The article concludes with a collection of related "how to sabotage" articles and promotional material for upcoming DevOps events.