There will always exist between the worlds of development and test a certain degree of friction. It just comes with the territory of being employed to point out the flaws another group made (which ultimately is what test does). This friction is good and keeps each other honest. Development cannot get lazy and let their output quality drop and test should be held to equally high standards. Things start to devolve however as soon as “We’re on the same team here” gets uttered. Normally it is said by someone senior (as in “responsible for project delivery dates”) in the development team within a month of the scheduled release date but could conceivably be said by test as well.

Let me translate that sentence for you. “Please stop finding problems with the code because it makes us feel/look bad and puts the ship date in jeopardy.” To which I say that is just too darn bad. Perhaps if you had done proper requirements development, design and unit tested each component as it was incrementally developed we wouldn’t be having this discussion. It also instantly aligns development into the “we don’t care about the quality of code, just that it keeps our on-time streak alive” camp, which may be accurate, but it is not something you want to advertise. Nothing gets under the skin of a tester than disdain for quality. These are people whose very purpose in life (or at least the work part) is to improve the quality of software. If a development manager openly shows schedule bias it becomes my goal to not only release the product with a high level of quality, but to make sure the development group works right up to the last minute.

Of course, this is all from the bias of someone who tests for a living. I suspect however that the marketplace is starting to also shift bias to overall quality; educated by CNN of all places. With the increase of more pervasive internet connectivity and the associated malware one can get online, there are more and more stories on the news about “critical hole in . apply patch from by “. This is getting the general public used to the idea of poor software quality. Eventually however, there will be a shift in consumer preference from “good enough” to “good”. It has already started I think, at Microsoft; the biggest of big in terms of traditionally poor quality. The Blue Screen of Death has transcended the geek domain and is now common parlance. Now Vista is way late and no one (except maybe the stock analysts) are screaming about it. Why? Because MS has said that they are keeping it in-house until all the kinks are ironed out. In other words, we’re boosting the quality.

So lets wrap up this little discussion with another analogy. Imagine your organization as a football team. Development would be the offensive line, and test is the defensive line. The overall goal of the team is to win the game (release the product, start collecting revenue etc). The objectives of the two teams are different however. (this is the important part) The offensive line’s purpose is to score as many points as possible (develop as many whiz-bang features) in the time alloted (by the ship date). You have all your high-paid talent (QB, RB etc) here that hurts when they are hurt. How resilient is your development team from losing a senior member or two? Bill Gates has said that MS is nothing if they lost the top 20 smartest people. The defensive line is to stop the opposing the team (bugs) from getting through. These people are not so much in the limelight but are just as (if not more so; spot the bias) important. A great defensive team can stop people all day, which is what a test team should do. Keep finding bugs. If the game / release goes into overtime, that’s fine. So long as the game is won in the end (or the product eventually ships and is of acceptable quality).

Okay. it needs some tuning still, but for now it will have to stand as it is for now.