Saturday, August 13, 2011

Testing is the cause of poor quality software

I'm going out on a bit of a tangent for this one but I think that's its got some merit.

Recently I was part of a conversation about all of the issues we'd discovered during a testing cycle. The back story is earlier this year a new test environment was built and we tested it. We tested the environment in-line with our current practices which is to run a suite of tests that tests all of the major components and system flows. This test suite can be completed in roughly 4 hours. If we were to run our complete system test it takes about 3 weeks and so taking a risk based approach we opted for the quick test cycle. This decision was predicated on the fact that this environment would be build using tested and approved build instructions which have previously delivered a stable and complete environment.

Fast forward to the conversation mentioned earlier. It went something like they said "Didn't you test it properly?" I said "Yes, we followed our standard process and ran the quick cycle tests" they said "well that's why all the defects, we need you to test it to make sure it done right." I said, well nothing... Pondering the conversation has lead me to believe the testing is the cause of poor quality software. Why, well because the folks who build the software rely on testers for quality control rather than focus on quality assurance themselves; With timelines never being long enough to build a proper solution of course there isn't enough time to test it before it goes into test. But that is ok, that's why we have testers, they test and they'll caught the bugs before they go into production.

So tonight, my thoughts are along the lines of if we get rid of the testers, then the folks who build the software will have to build and test; therefore the quality of software will increase and shift away from the compliancy of the testers will catch it! After all those testers take so long to test anything...