There are many views of Quality Assurance in IT.

Some see it as unnecessary overhead, an expensive hurdle to cross before systems can be turned on in a production environment.

Some see it as a form of contingency in the schedule, something that can be shortened or skipped if there are schedule overruns in other parts of the project.

Some see it as a gatekeeping function, making sure the operational pre-production activities have been met before development throws the systems over the wall for operations to catch, operate and manage.

Some see it as a bolt-on process, to catch and correct obvious errors.

Some see it as a validation of good design and good programming practices.

Some see it as a way to prove the concept without interrupting the real flow of business.

Some see it as a good way to build in extra resources for use in disaster recovery an/or business continuity situations.

Some see it as a training tool to give the end-users a chance to see the new/changed system before it becomes a part of their work process.

Some see it as a cost-reduction/cost avoidance strategy, as finding and correcting defects in test is much cheaper than having our paying customers finding and sometimes reporting defects in production.

Some see it as a balance between getting a product or service to market and making certain that the product or service is sustainable in the market.

I’m certain there are many other points of view, I believe it is important to surface those views within an organization and work towards developing a common, affordable view that fits the culture of the organization.

Quality Assurance can be a competitive advantage if you are willing to do the work and pay the price. It can be a differentiator when competing for new business, it can help protect current business and it can make/keep your customers happy.

Quality Assurance will be a necessary evil if it is only an afterthought in your organizational design.

The choice is yours.