国内为数不少软件企业虽然经过多年的发展，但仍处于疲于奔命、停滞不前的局面；另一方面，规模像“作坊”一样的小公司，几乎每天都在诞生、消亡。导致公司兴衰成败的原因是多方面的，笔者以为其中一个最重要的原因是软件产品质量的好坏。（当然，市场策略也是其中一个极为重要的因素。）几乎所有的企业都想对自己已有的技术成果或项目成果进行产品化，然后再把产品市场化、国际化。可是，绝大多数企业的软件产品一旦走向市场就会遭遇重重困难，例如，软件质量不过关，软件可维护性差，软件使用学习周期过长等等问题。本文不打算深入剖析决定软件企业及其产品成败的各个因素，而是侧重于测试角度，以案例的形式，对软件企业中影响产品质量提升的常见错误认识作一些分析并给出解决方案。
软件公司在产品开发中，通常存在三大不合理现象，它们严重影响了产品质量的提升：
1）为了保证产品的工期和进度，文档、质量管理、测试、评审等一系列工作统统可以忽略；
2）为了早日推出产品，不进行正规的缺陷管理，导致缺陷反复出现，缺陷较多的问题不能从“源头”进行控制；
3）发生质量问题不好好反思自己产品开发管理方面的不足，进而从最根本处入手解决问题；而是掩盖真实原因，追查个人责任。
本文将针对这三大现象，以真实的案例为蓝本，逐个进行剖析。
1、进度 VS 质量
本案例是非常典型的产品开发案例，几乎是很多中小公司的典型做法——以按时发布产品和进度为理由，不实施任何测试工作，就更不用说质量保证工作了。
下面是案例的一些基本信息：
产品信息 | 内容 |
产品名称 | 系统为J2EE结构的某行业的ERP系统。本产品是一个来源于项目的产品，原有客户和新的客户已经投入使用部分功能。 |
开发人员 | 产品开发人员10人。 |
功能模块 | 含有工作流流程的模块有30个，不含工作流流程的普通功能模块20个左右。 |
进度要求 | 当时计划一年内开发完成，实际目前已经耽误进度0.5年。 |
产品现状 | 主要功能基本完成，而且在一些新的客户中投入使用，反馈问题较多。 |
下面是产品开发的过程：
阶段 | 过程 | 大事记 |
项目立项阶段 | 三家大客户准备采用该产品，公司把三个项目在内部作为一个项目来开发，同时制定要把该项目成果产品化的目标。 | 为了赶进度，采取封闭开发的方法，同时决定第一版不进行测试。 |
第1个月 | 项目在没有文档的情况下进入开发状态，主要参考依据是公司内部基于另外一个平台的同类产品，该平台有些过时是开发这个产品的主要原因。 | 产品整个开发过程基本没有进行关键方案、文档的评审工作；没有进行任何测试；没有任何质量保证人员。 |
第2～5个月 | 产品正常开发，大多数功能由程序员做主进行开发。同时，开发完成的部分准备安装试用。 | |
第6～12个月 | 开发团队进一步开发产品； 实施人员在现场安装已经完成的部分，同时做缺陷修改工作； | 第六个月时，客户开始对公司施压，要求尽快安装全部产品，同时拒绝使用已经安装好的部分产品； 几个实施工程师以超人的“救火”能力，解决了现有缺陷，在几乎没有提供新产品的条件下撑过了半年。 |
第13个月 | 把主要功能提供给客户进行安装； | 前面的几位实施工程师在季度会议上，被公司评为了“英雄”，给予了一定的奖励，鼓励他们继续坚守阵地。 |
第14～18个月 | 公司决定把产品交给现场的实施人员进行维护，专注产品化工作； 确定在接下来的6个月推出新版本的目标； | 由于缺陷较多，现场用户抱怨不断； 实施人员忙于现场“救火”。 |
第19个月 | 所有的开发人员不再兼顾项目，加班加点准备按时发布产品。 | |
…… | …… | …… |
现实中很多公司目前都是这样进行软件开发的，几乎很少进行测试工作，最多也就是在产品发布后进行最后的“用户测试”和一些功能性测试。当软件系统在用户那里出故障了，现场补救成功的人成了公司的英雄，好心的用户甚至还会因此寄来感谢信。然而这并不是真正合理的做法。如同案例中描述的那样，这会导致现场用户抱怨不断，分配用于“救火”的工程师越来越多，最后导致企业不堪重负，不得不放弃部分现有客户的系统维护工作。要想改变这种现状，应该从以下几个方面入手：
不但要主观认识到测试对软件质量的重要性，同时还要落实到行动中。
测试的重要性已经逐渐被软件开发团队认可。但是落实到实际工作中，通过测试真正提高软件质量，还有一段很长时间的路要走。因为几乎所有的软件公司都灌输着“进度高于一切”的思想，只要是为了赶进度和发布产品，所有影响进度的工作都可以忽略。
