I’ve been coding for something like twenty years, but I’ve only really been testing that code for about ten. Oh, sure, I would bang on my apps in ways I thought were similar to what my users would do, and I stepped through my code and stuff like that, but I didn’t really know what I was doing.
I knew that something was wrong, though. Making the same mistakes and fixing the same bugs time after time tend to help a person come to that conclusion. <g/> Code Complete and Writing Solid Code and Testing Computer Software were like bolts of lightning directed straight at my brain. My code got better and my users got happier. I still didn’t really know what I was doing, but at least I *knew* that now!
Then I discovered unit testing. Talk about your life-changing events! Now I could write consistent, repeatable tests that were easy to run. Once again, my code got better and my users got happier. That combined with a whole lot more reading meant I was starting to actually know what I was doing.
Fast forward to now. One of my primary responsibilities is helping my team move along this same path in rather a shorter amount of time than I took to travel it on my own. I’m happy to say everyone is making great progress — which is a good thing, since we have a bloody lot of code to write! Our automation stack (and its unit tests!) makes for a good chunk of code, but it doesn’t end there. We have all those test cases to write, too. Some of our pairwise test cases are turning out to be quite complex; certain of them are more complicated than some of the production code we’re testing, I think! One of us estimated recently that we’re writing twice as much code as Dev is; I don’t think that statement is far off.
We have so much still to do, in fact, that Dev is pitching in for several weeks. How cool is that?!? We have pretty good communication between Dev and Test, but it’s not as good as it could be, and having them working on our tests can’t help but make that communication better.
Our developers write integration tests for the code they write using our automation stack, but this few weeks are immersing them in our world much further than they’ve gone previously. They are actually spending entire days doing nothing but writing test cases. Not application code. Test cases. And they’re starting to understand why we do all the strange and weird things we do! Just this morning I overheard one developer talking to another about verification: “I just cleaned up a whole bunch of problems that Test has been complaining about for awhile. I never understood why they cared — they were minor issues that didn’t have any visible effect. But when you have to verify all this data in all these test cases, and you can’t just hard-code in ‘expected’ deviations like these, those minor issues become major issues! I guess I knew this before, but I hadn’t really internalized it until now.”
Oh. My. Gosh. Developers starting to get testing! They’re doing a great job, too! Which just proves my long-held theory that developers can be trained. <g/>
*** Comments, questions, feedback? Can you test? 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 tester and my team needs a data binding developer (i.e., a developer that wants to play with databinding), program managers, and a product manager. Great coding skills required for all positions.