My Job Is *Not* To Write Test Cases
"But my job is to write test cases!" my friend said, almost plaintively. We were discussing the huge amount of work we have to do and the not-nearly-enough time in which we have to do it. I was relating my strategy: get my developers to do all the testing! Dev is going to be doing unit testing anyway, I figure, so I may as well get them to do as much of my testing as possible. It's a matter of best leveraging my skills and time. Given the choice between spending ten hours writing tests myself, or spending that same amount of time working with ten developers to brainstorm ten sets of test cases that they write after I leave, I'll take the latter every time!
"Wait a minute", you may be thinking. "You seem to be saying that your time is more important than your developers' time. That's rather arrogant, don't you think?"
It's not that anybody's time is more important than anybody else's time. My job is not to write test cases. Likewise, my developers' job is not to write code. Our job is to create a high quality application that solves our customers' problems. That's it, full stop.
The best way I know to do that is to keep the quality high at every step along the way. So I help my feature team think through ideas before they're ever written down, when bugs are trivial to fix. I test my specifications before they're codified into code, when bugs are easy to fix. I work with my developers to identify unit tests that will catch bugs before they're checked in, when they are still fairly cheap to fix. And of course I execute a plethora of manual and automated test cases on my application, when bugs cost more to fix but haven't yet affected customers.
So yes, my developers write lots of code. And yes, I certainly write many many test cases. But that's not what we're being graded on. And that's why writing test cases is *not* my job.
*** 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 coding skills required.