Software Testing Vices: Funny Examples of Root Causes

Every vice in software testing and quality assurance belongs to one of four categories of root causes.

They are:

• Apathy — complete ignorance of a testing process;
• Arrogance — labor “blindness” that leads to the appearance of errors and making incorrect decisions;
• Corporate ignorance — when nobody has showed you how you should work, you start to think in an incorrect way;
• Professional helplessness — gradual cognitive exhaustion as a result of struggling with organizational dysfunction.
  

  Root Causes of Testing Vices

Further, we’ll give you a list of the most popular vices of testing that can somehow affect an entire career of a QA Specialist.

1. A client won’t use the software in the same way as you do;
2. You started testing this too early;
3. As a result: you tested the software too late;
4. Do you need to be present at a meeting where the design will be discussed?
5. A code review meeting can be held without you;
6. You don’t need to be present at a meeting where requirements are gathered;
7. Can you break this?
8. As a result: users have never complained about this;
9. Let’s see — it still works;
10. Test it right now;
11. How did you manage to break this?
12. When was the last time it worked properly?
13. I haven’t edited anything, right?
14. How could I know that software had been updated?
15. I can’t tell you what test to write, it’s your work;
16. There will be a huge update, that needs to be tested in one go;
17. How do you analyze backend bugs?
18. Could you explain: are these errors interconnected?
19. You meet this bug regularly but we don’t; can you explain why does it happen?
20. Your tests fail constantly;
21. We will give you three extra days so you will have a chance to retest it rapidly;
22. I am just a manual tester;
23. As a result: I am an automation specialist;
24. Every developer should be familiar with software automation;
25. You don’t need to change this configuration file;
26. This release will make software work faster;
27. Test this product and I will document this design meanwhile;
28. Refactor it in one go;
29. This hasn’t been mentioned in a list of tasks;
30. Why do we need 100 cases on a project?
31. As a result: all tests have been passed;
32. This environment is for development only;
33. As a result: everything will be different in real conditions;
34. Nobody will need my tests when I execute them;
35. As a result: the test code is not production code.