Now that I’ve been in my new job a few weeks you might be wondering how many bugs I’ve found. I’ve found exactly one, and that was only because a unit test hung on my machine. (On a line of code which had a comment that maybe the operation needed a timeout. Um, yes please!)
There are many different reasons I have not yet found any bugs. One is that I own three features, each of which is at least a full-time job. Another is that I haven’t gone looking for bugs as of yet. A third reason is that I don’t have anything to test yet.
Oh sure, there’s bunches of code for one of my features. It’s nowhere near ready to test yet. The developer agrees. I’ve read through the code, and the unit tests he’s written so far. Much of the testing for this feature can be done at the unit test level. I’m working with the developer to identify additional unit tests. I may even write some of them.
I do have multiple specs for each of my features, which I’ve been perusing. I’ve asked countless questions about the features. Not all of them have answers yet. Some might say I am testing the specifications; I don’t quite see it that way.
I also have oodles of specs for the rest of the system. There is a lot to come up to speed on.
These are all details. The overarching task in which I am engaged is sucking in information and figuring it out. This is one of my strengths: gathering copious amounts of information, shifting it about, and then forming it into a set of concepts and theories and models and such. Thinking about the various ramifications. Formulating ideas for how to test it. Pestering my PMs and developers with questions upon questions upon questions. Writing my test plans. Organizing my test missions.
This is my favorite part of any project. Not because I don’t have code to test. Not because I am identifying holes in what we think we know. Not because I foresee lots of fun code to write. Not because I am in-my-brain testing all this stuff which doesn’t exist yet. This is my favorite part of a project because I am learning pretty much full time. An acquaintance once told me that no one likes to learn. Not me! I love to learn. When I stop learning I get bored. Usually I drop the whatever-it-is and move on to something else.
This is one reason I am a tester rather than a developer. Developers have to take their code all the way to the finish line, whereas I lose interest as soon as I learn enough about the problem to know it is solvable. (Which, in some cases, yes, means taking it to the finish line.)
Testing, on the other hand, I see as an NP-complete problem. There are any number of questions which may be unsolvable. I don’t see me getting bored with testing anytime soon!
Am I finding bugs right now? No, I am not. Am I testing? Yes I am.
*** Want a fun job on a great team? I need a tester! Interested? Let’s talk: Michael dot J dot Hunter at microsoft dot com. Great testing and coding skills required.