Milestone Ho!
We're currently in the interregnum between milestones. Rather than rushing in to the next milestone the day after we exit the current one -- which means you must steal time and energy from this milestone to focus on the next one, and/or enter the next one without really knowing what its goals are and how you'll be meeting them -- we stay on target through the end of the milestone and then spend a month focusing on nothing but the specifications for whatever we're doing in the next milestone. No coding, although there is lots of discussion about how exactly those features should be designed, and lots of prototyping isn't unusual. No testing, although there is lots of discussion about how we will test those features. And of course lots and lots and lots of discussions about what exactly the features are and how they should work, of which the aforementioned discussions about design and coding and testing are an integral part.
That's the theory, anyway. Reality is a little more messy. Spec reviews started several weeks before the milestone ended. Dev has been doing nothing but fixing bugs for the last several weeks and is champing at the bit to start "real" coding again. (Yes, I know that if they just wrote better code to start with that pain would go away, but developers are masochistic it seems.) They always have infrastructure work to do -- which is to say coding that doesn't require a feature team but must nevertheless be tested -- and of course parts of their prototypes often find their way into the production code. Test still has a bunch of not-quite-important-enough-to-hold-up-the-milestone-for testing to do in addition to whatever testing is needed by the infrastructure work, plus we have our own infrastructure work to do as well. PM and Test are behind the curve, Dev is making somewhat of an effort to not jump the gun but partially failing, and at times it seems like we are no better off than teams that don't even pretend to separate milestones.
We are better off, though. My current team is better in this regard than any other team I've been on, and we're actively working to improve. But it's still frustrating when Dev says in the last week of the milestone, "The specs are good enough for us so we're ready to start coding. Test isn't going to drag things out very long, are you?"
Umm, yeah. That's right. Test is the one holding everything back. As if.
Yes I'm a little grumpy, a state I don't enjoy. My plan for getting ungrumpy has two components. First, help our feature teams become just that: not a dev and a tester and a PM in the same room talking about mostly the same thing but rather a team discussing the problem they're trying to solve, how they plan to solve it, and how to tell whether they in fact solved it correctly. Second, help Dev better understand that Test's job is not to do all the testing they didn't bother to do but rather assist them in doing that testing, and then take those well-tested-in-isolation components and verify they play well together.
As I said last time, Test is not responsible for ensuring the quality of the product -- that's the whole team's job. Likewise, Test is not responsible for ensuring the code Dev writes works correctly -- that's each developer's job. Test's responsibility is to help the feature team build a quality product and to help Dev build well-tested code. This means ferreting out the holes, inconsistencies, and fuzzy areas of the spec. This means understanding Dev's design well enough to intelligently discuss ways it's likely to fail and to partner with Dev to brainstorm the best way to test it. This means looking at all the expected and unexpected ways each feature interacts with each other feature and ensuring that something sensible results. This means banging on the app mercilessly to root out the many different problems that will cause the app to die, and checking that when it does die it does so in a safe, recoverable fashion that doesn't lose the user's data. This means understanding our customer and seeing and using and testing the product from their point of view.
When our feature teams are firing on all cylinders all the time, and when everybody (including my testers!) understand what exactly our job is and what it isn't, I'll be a lot less grumpy.
*** Comments, questions, feedback? Want a fun job on a great team? Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com. I need a senior tester and my team needs program managers. Great coding skills required for all positions.