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.

Comments (12)

  1. Naveen says:

    Cool post :).

  2. Sherman says:

    My thoughts exactly =)

    I’m glad that you said that actually. I was referred by some MS friends to read the following comments concerning DEV vs TEST vs PM. Some people have very strong feelings and misconceptions about Testers only testing and automating.

    ( — halfway through the comments, the discussion begins…

    Have a good one!

  3. Jim says:

    Are you a SDET at Microsoft? Or do they have a separate group of software testers?

  4. I am an SDET (Software Design Engineer in Test). However, an STE’s (Software Test Engineer, where one difference is that STEs tend to do mostly manual testing) job isn’t to write test cases either.

  5. Scott Loveland says:

    Good post. I like to take this concept one step further, and ask those before my in the food chain to write test cases such that will fit into my automation framework. Not really any extra work for them, it’s just a matter of certain choices to make when writing the test case. That way I get a nice workload I can run periodically to ensure that recent code changes haven’t regressed previously tested function. And it’s basically free.

  6. Stella says:

    "working with ten developers to brainstorm ten sets of test cases that they write after I leave" — How do you work with them on this?

    BTW, I want to see the comments Sherman posted. but i can’t open the link…

  7. Hmmm…the link opens for me. No idea what the problem might be.

    My conversations with developers usually start out something like "I have some ideas regarding what needs to be tested for Feature X. Would you like to hear them?" They say yes, and then we’re off and running.

  8. Michael – I am going to start doing this on my team and report how successful I was in getting my devs to write tests that I recommend. Wait on that one…

    – Anu

  9. Stella says:

    Seems you and your DEVs work very closely. And you involved in the process before code complete. So that code quality is higher when completed…

  10. Our feature team works together throughout the entire lifecycle of the feature, from before the spec is written until the last bugfix is in. Most definitely code quality is higher than it would be if we got involved later in the process!

  11. Stella says:

    I think lifecycles are crossed. Meaning when one cycle is not totally finished, the next cycle begins and some people released to do next cycle’s tasks. for example, in the latter phase of the cycle, PD seems have time to design next generation’s comment. But QAs have no time to get away. So how could QA and PD and Dev to work together in the former phase of the cycle (product design phase)?

  12. Test is certainly never finished. The solution I think is first to make a clear statement as to what "finished" means for a milestone: all BVTs, FVTs, and Exit Criteria passing 100% and all other tests analyzed 100%, for example. Then you have to work with Dev and PM to ensure they understand what that means and get them to agree to not move on until that point is reached. But planning for the next milestone almost certainly will happen during the current milestone, so you have to build that into your schedule.

    The best way I know to get the entire feature team working together throughout a milestone – from initial design through signing off on the final product – is to integrate each discipline’s concerns into the feature spec. If your feature specification includes details about what tests are going to be written, for example, it’s much more likely that Dev and PM will be thinking about such matters from the start.

Skip to main content