The only way to succeed is to fail. Therefore, fail early and often.
Think about the last time you attempted something new and you succeeded right out of the gate. Do you have any clue why? Do you know whether the approach you took is the only one that would have worked? Do you know whether every step was actually necessary?
You can’t know these things after doing something just once. So: the next time around, will you do it exactly the same as you did the first time – being as you know that way works and all – or will you do it differently to learn what happens?
If you always do a task the same way because you know that way works, you aren’t learning anything about that task. Which is not necessarily bad – perhaps you have already done all the learning about it that you want to do, or maybe you are taking advantage of someone else’s learning about it (which is to say you’ve already done all the learning about it that you want to do). After all, if you always do something a certain way because you know that way works, you generally don’t have to worry about failing at it. The “Failure Is Bad!” syndrome that pervades most societies constantly pushes you to take this option.
If you’re lucky, however, your family encourages you to fail early and often. If you’re really lucky your teachers do as well. It takes a lot of courage to fight against this, but the rewards are great. Learning doesn’t happen from failure itself but rather from analyzing the failure, making a change, and then trying again. Over time this gives you a deep understanding of the problem domain (be that programming or combining colors or whatever) – you are learning. Exercising your brain is good in its own right (“That which is not exercised atrophies”, my trainer likes to say), plus this knowledge improves your chances at functioning successfully in new situations.
Which of course is where testers find themselves every day. Every new build you install is different than the previous build. For all practical purposes, it’s completely new. If you are afraid to fail then you will be paralyzed, because you have no idea what you will have to do to break that application. All you can do is try a bunch of things – most of which won’t cause your application to misbehave. This is what testing is all about. Finding those five scenarios where your application malfunctions is important requires finding five hundred other scenarios where it works correctly. (Which set is more important is a question I’ll leave for another day.)
When you are constantly failing it can be hard to discern whether you are actually succeeding or just flailing about making negative progress. One way to decide is to periodically look back to some point in the past at the tests you executed or the code you wrote or the colors you combined then. If you are completely embarrased by what now seems a naive test case or badly designed code or a clashingly bad color combo, then you are definitely making progress! <g/>
*** Want a fun job on a great team? I need a tester! Interested? Let’s talk: michhu at microsoft dot com. Great coding skills required.