I read a post from the Google Testing Blog tonight called Introducing “Testing on the Toilet”. The article was moderately interesting, and I’m a believer in the value of unit tests, but what really caught my attention was this comment:
> Hm. I have to say, I think this is misguided.
> I’ve worked for a long time in the testing/QA engineering field for software (seems like every company calls it something different, and there are different expectations of each, but that just leads to my point). My point is that QA needs to have a bright line between it and development. No doubt, developers need to be good at creating good unit testing. By the same token, good QA/Testers need to be good at development.
> But the two should remain separate. Go to any mature industry’s engineering department, and ask how much of the release testing is done or defined by the actual development engineers. The answer will be you’ll be laughed out of the office. There’s good reason for this.
> This is a sign of the immaturity of the software development industry. We’re getting there, though. I’ve worked for a couple of the truly big Seattle software interests, and they are slowly getting more mature in how they deal with QA. The key is, (for as good and happy as developers doing a good job developing unit testing for their own work): SDEs are not QAEs, and the distinction should not be blurred, if you want to maintain true quality.
I disagree with this assessment with my whole entire heart, and here’s why.
First, unit testing is documentation, and all code should be documented. If you write good unit tests to go along with your code, then any other developer can look at what you’ve written and be able to determine exactly what you meant to have happen in theory and, if they run your test suite, whether what happens in theory and what happens in practice line up.
Second, if you’re not writing unit tests, you’re not thinking about edge cases very thoroughly. When I’m writing code, I try to consider the outliers and uses other than its intended one, but it’s usually not until I make a pass to flesh out my tests that I really start to see the edge cases clearly. Yes, I just admitted that I am not usually a tests-first developer… I hope that doesn’t come between us.
Third, nobody knows your code like you do. If you move on, get fired or get hit by a bus one day, someone else will have to maintain and modify it. And while you might think it will be an amusing exercise for them to go back through all the spaghetti code that you wrote when you were in a hurry, I promise you: if you have not documented (tests are documentation, remember), they will hate you for it.
So, while I guess I can see the value of having a QA department to make sure that everything is working before launch, I fundamentally disagree with the idea that development and testing should be separate from each other. If you can’t test the code you’ve written, I don’t think you’re really a developer at all.