笔者从事软件行业相关工作将近十年，其中与测试相关时间有7年之久，现浅谈软件项目管理中测试的必要性，供大家参考。
一、测试的必要性
为什么需要测试，那是因为由于分工的精细化，软件开发必须经历客户、需求、设计、开发多个环节。为了保证最终的结果符合要求，上下游是需要确认的。
用户告诉我们：我需要什么？软件企业需要在理解正确、表达正确的情况下完成需求规则说明书，把客户的原始需求转变为IT需求，表达出能够提供什么
需求的下一环节是设计，设计主要是要要说清楚：我要让软件做什么。需要与前一环节确认理解正确了、设计正确了、表达也正确了
接下来就是实现了，程序告诉计算机怎么做，最终保证能够运行出结果，而且运行的结果与用户要求是相符的。
正式因为一个项目参与环境众多，为了保证客户需求在传递过程中尽可能少的丢失，我们需要反复的校验、确认，也就产生了测试。
传统的观念中把测试定位于从程序员到运行结果这一段，实际上强化每个阶段的确认、特别是用户需求到需求规格的确认，是更能节省时间和成本的方法。
首先回顾一下PMI协会关于质量管理的一些观点：
第一点就是质量管理的最终目标是使客户满意，质量管理的定义就是理解、评估、定义和管理客户需求，以达到客户期望；能使客户满意的标准就是符合要求且易于使用。这是一个从项目角度出发提出的概念，针对产品研发也应该是吻合的。研发出的产品是为了卖给客户的，不是为了孤芳自赏的，所以研发成果是否满足客户要求也是至关重要的。
另外一点就是关于功能性符合度和易用性符合的强调，现在很多企业很容易聚焦于功能而忽视软件最终是给人使用，是给不同文化层次的客户使用的，软件的易用性往往能够推翻软件企业为了实现功能所做的一切努力。
举例来说，有一个项目，需要实现两种产品单据的传递，因为交付工期很短，我们的开发人员加班加点的完成了功能，但是客户却拒绝接收。原因在于引入单据之前需要进行两种产品基础资料的匹配，开发实现了这个功能，却忽视了客户有大概2000条基础资料需要匹配，没有提供批量匹配的功能，最终客户试用中感觉工作量无法接受，拒绝验收了。前面所有加班所有的努力都白费，原因就是忽略客户的易用性需求。
可能对于产品研发而言，没有这么强硬的结果，但是一些功能不好用对客户满意度的影响还是相当多的。所以个人认为把产品通过测试的标准定位与符合要求且易于使用是非常恰当的。
第二个观点是预防胜于检查，这是很容易明白，但是实际过程中又不大容易做到的。因为客户的压力，很多企业的发版是很频繁的，发版之后是否有人来总结这次版本研发中碰到了什么问题，哪些缺陷影响了发版时间，下次版本中需要一些什么预防措施？如果没有这样的一个过程，没有缺陷的一套分析和预防机制，很多类似的问题会不断的出现，版本的质量以及补丁的压力会像滚雪球一样越滚越大，最终使得整个研发团队难以负荷。
第三个观点是关于管理层责任的，提出PDCA循环的戴明就说，85%的质量问题应该由管理层负责，只有15%的责任是团队负责。很浅显易懂的一个道理，假设公司老板对你说，这个版本你一定要保证质量，有一个问题都不能放行！你想这个版本质量能差吗？
