- lessons learned stories and project collective memory.
My discipline and practice as a very low-level test master, helps me know which things to try, and if one fails, I try another. As a test manager, my job is to know all these concepts exist, and to try until I find something that works for my team at a given point in time. I am here to help communication, aid understanding, and not make judgments, except when my job requires a decision with the group. I help people in the team. And because of the evil multiheaded beast of complexity, I don't expect the other team members to be masters of testing. I expect them to be masters of what they do, which will help me, since I am not an omni-capable master. We work on priorities. We work on risks. We focus on problems. We focus on code. We all test. We all code. We all try to understand the problem. No, wait you say. This sounds very agile. Yes, but agile with documentation, plans, processes, and procedures. Oh, so you are really traditional? Yes, but why do I need to be one or the other?
I am depending both on the time and my problem. Can I not use parts of both? People that are hard over on one side of the agile vs. heavyweight-process debate will have problems with me. Good. The beast of quality has no single head, and those people that sell concepts of a single head will find that it only works sometimes. Complexity requires multiple approaches. I can't be static and unchanging.
When managers ask what I do and why testing is necessary, I must help them to understand the complexity and communication problems in software. Managers, as most humans, tend to oversimplify problems. Humans test things all the time. Nobody would buy anything expensive or complex without some kind of evaluation. If managers can't get this "fact of nature," their projects are probably doomed. Marketplace Darwinism will require correct levels of quality, not perfection, but good enough quality where people will continue to buy the software. The team must balance this and the complexity. I bring my mastery of testing to the team. I work with all of the team to improve my mastery. I am never good enough to stop. People that say otherwise have missed the boat, and the complexity beast will get them.
Next time somebody asks why and how you test, consider my list, but wait. This list is not complete and probably not right for you. You should always ask yourself "Why." The answer may change over time. Next time you want to justify going to a conference or training, start with this list, and add your own items. Learn why you test to improve you test skills.