cogitatio

In many young software companies, there isn’t an individual role for for software quality assurance.  The assumption is that between the development resources and the product stakeholder the software can be sufficiently tested to get you past the initial profitability hurdle, and through your first BETA and initial release.  In the very early days, this suffices.  It will get you to a point where the software is sufficiently stable that it can be used for the limited functionality contained in the first early releases.  That said, it is imperative that quality assurance becomes a stand alone role within the organization relatively shortly after the early stage releases of the software product.

Quality assurance is yet another area that is easy for executives outside of the development organization to write off as merely a “cost center” that doesn’t directly contribute to incoming revenue streams.  They couldn’t be more wrong.  It is rare for an organization to take the time to do an accurate assessment of exactly how much money bugs cost them.  I won’t go into the long litany of the costs associated with software defects, they can range from losing money on orders placed to losing customers due to software that doesn’t perform as specified.  Yet this doesn’t answer the question of why developers are poorly suited to acting in this role.

Unless you have a particularly small software organization, developers will have relatively specialized expertise in their niche of the software platform.  As the software platform evolves, this becomes more and more true.  And this is a good thing.  Noone can be an expert at everything (a topic for a post later this week).  You want your developers to become experts in their area, and not have to worry about being experts in other parts of the software platform – this produces the highest quality software product because people can focus on what they know and develop the best solution within that area.  The downside to this specialization is that developers may not have full knowledge of how changes in their area affect other parts of the application.  Beyond that, as developers are tasked with producing results, it’s not rare for developers to develop tunnel vision.  A development team member may be told that within the problem domain x, f(x) should result in y.  Then they try to produce this result given known or sane values within x.  And this is great, until a reasonable but unanticipated x value is given.  As the software complexity grows, these problems increase exponentially.

This is why the role of quality assurance engineer is absolutely crucial.  Their focus is on the consumer of the software, the customer.  They can look at the problem outside of the niche domain, and they can produce a better subset of test cases as a result – test cases that are likely to far exceed the scope of the test cases that the software developers would conceive of.  Further, they provide a valuable feedback loop into the development process that can take the software platform in new directions.  Software Quality Assurance is not a cost center, it is a cost saver.