During my first month as a QA Engineer, I bumped heads with my peers many times over defects. Fundamentally, I’m the type of person who believes that if you find a bug – then it should be fixed. Their argument was that bugs should only be fixed when the benefits out way the potential problems. An unfortunate example of this happened last year when a newly hired development engineer “fixed” something in common code – causing chaos as all the modules which had “worked around” the problem broke. After a week it was decided to give up trying to sort out the mess and just revert the dev-tree.

As far as the second class of software testing, which relates to specs, I’m very wary of those types of developers and testers. If you have a perfect spec – then great. This is something you which is so rare you may never experience it. However, what happens when the spec is worthless and the only way you can create a decent product is to abandon it entirely. This recently happened on one of our products – the spec was abandoned because the person who wrote it didn’t know anything about how to make a decent web product.

As far as TDD – I’m probably in the skeptical camp. If anything, I believe in DDT – development driving testing. The idea that I’ll experiment with a solution before settling on it. Test driven development causes too much lock-in. The earlier you write a test case, the more likely you will have to change or drop the test before it has a positive ROI (Return on Investment). So much of this depends on what you are developing.

A developer can never prove more then Happy Path testing, since they can never know what false assumptions they have about how others may view the product. The invisible wall between QA and Engineering exists for this very reason. We may encourage Engineers to test their code, but we certainly don’t believe them when they say it won’t break.