浅谈软件项目管理之测试.doc

浅谈软件项目管理之测试
发布时间: 2011-11-21 11:14    作者: 未知    来源: 51Testing软件测试网采编
　　笔者从事软件行业相关工作将近十年，其中与测试相关时间有7年之久，现浅谈软件项目管理中测试的必要性，供大家参考。
　　一、测试的必要性
　　为什么需要测试，那是因为由于分工的精细化，软件开发必须经历客户、需求、设计、开发多个环节。为了保证最终的结果符合要求，上下游是需要确认的。
　　用户告诉我们：我需要什么？软件企业需要在理解正确、表达正确的情况下完成需求规则说明书，把客户的原始需求转变为IT需求，表达出能够提供什么
　　需求的下一环节是设计，设计主要是要要说清楚：我要让软件做什么。需要与前一环节确认理解正确了、设计正确了、表达也正确了
　　接下来就是实现了，程序告诉计算机怎么做，最终保证能够运行出结果，而且运行的结果与用户要求是相符的。
　　正式因为一个项目参与环境众多，为了保证客户需求在传递过程中尽可能少的丢失，我们需要反复的校验、确认，也就产生了测试。
　　传统的观念中把测试定位于从程序员到运行结果这一段，实际上强化每个阶段的确认、特别是用户需求到需求规格的确认，是更能节省时间和成本的方法。
　　二、测试管理与质量管理之间的关系
　　首先回顾一下PMI协会关于质量管理的一些观点：
　　第一点就是质量管理的最终目标是使客户满意，质量管理的定义就是理解、评估、定义和管理客户需求，以达到客户期望；能使客户满意的标准就是符合要求且易于使用。这是一个从项目角度出发提出的概念，针对产品研发也应该是吻合的。研发出的产品是为了卖给客户的，不是为了孤芳自赏的，所以研发成果是否满足客户要求也是至关重要的。
　　另外一点就是关于功能性符合度和易用性符合的强调，现在很多企业很容易聚焦于功能而忽视软件最终是给人使用，是给不同文化层次的客户使用的，软件的易用性往往能够推翻软件企业为了实现功能所做的一切努力。
　　举例来说，有一个项目，需要实现两种产品单据的传递，因为交付工期很短，我们的开发人员加班加点的完成了功能，但是客户却拒绝接收。原因在于引入单据之前需要进行两种产品基础资料的匹配，开发实现了这个功能，却忽视了客户有大概2000条基础资料需要匹配，没有提供批量匹配的功能，最终客户试用中感觉工作量无法接受，拒绝验收了。前面所有加班所有的努力都白费，原因就是忽略客户的易用性需求。
　　可能对于产品研发而言，没有这么强硬的结果，但是一些功能不好用对客户满意度的影响还是相当多的。所以个人认为把产品通过测试的标准定位与符合要求且易于使用是非常恰当的。
　　第二个观点是预防胜于检查，这是很容易明白，但是实际过程中又不大容易做到的。因为客户的压力，很多企业的发版是很频繁的，发版之后是否有人来总结这次版本研发中碰到了什么问题哪些缺陷影响了发版时间，下次版本中需要一些什么预防措施？如果没有这样的一个过程，没有缺陷的一套分析和预防机制，很多类似的问题会不断的出现，版本的质量以及补丁的压力会像滚雪球一样越滚越大，最终使得整个研发团队难以负荷。
　　第三个观点是关于管理层责任的，提出PDCA循环的戴明就说，85%的质量问题应该由管理层负责，只有15%的责任是团队负责。很浅显易懂的一个道理，假设公司老板对你说，这个版本你一定要保证质量，有一个问题都不能放行！你想这个版本质量能差吗？
　换一种场景，你告诉老板有几个核心问题还没有解决，没有达到发版条件，老板却说，客户压力大，你先发出去，后面再出补丁！结果又会如何呢？
　　老板当然不可能忽视客户对工期的要求，不惜一切代价的保证质量，但是当成本和质量进行权衡的时候，老板会偏重哪一个，直接影响最终产品的质量；
　　老板在质量文化减少方面、过程改进方面重视的程度，也将直接影响这个公司所有产品的质量。
　　这就是管理层的责任！
　　提出这个观点的戴明还有一个观点与PMP相关体系非常符合，即质量并不是由工作人员的能力决定的，而是取决于如何开展工作的程序和制度。之所以要进行项目管理的认证，就是要让项目管理的整体能力不因为个人能力产生较大起伏，如果都能按照组织确定的流程进行相关活动，最低水平也能被保证。
　　第四个观点是持续改进原则，持续地、渐进地改变来改善情况，中国的俗话也说的好：饭要一口一口的吃，别想一口吃成一个胖子。
　　那测试管理到底与质量管理有什么关系呢？
　　在量管理活动中，测试是质量控制的重要手段。
　　三、测试相关原则
　　上图中也提到了测试的基本原则，在此做简单描述，欢迎大家拍砖。
　　1、尽早测试原则
　　尽早测试原则与马丁分析出来的结论有非常大的关系，一个缺陷在需求阶段被发现所产生的纠正费用是产品交付后维护阶段发生费用的两百分之一。
　　有软件公司也曾经做了简单测算，1个缺陷留到客户处被发现，所耗费的成本在50万左右。
　　或许引起客户怨声载道的严重缺陷，在需求环节解决只需要增加一行字的清晰描述，在编码阶段只需要多增加几行代码，可是一旦到了客户哪里，便成了投诉、安抚、补丁、责任追究等一系列的紧急事件。
　　2、Good-enough原则
　　Good-enough原则其实是针对测试本环节来说的，也体现了项目管理思想中关于质量和成本直接的关系。如果以精益求精的思想，能够到底“零缺陷”是最为完美的一种状态。可是从投入产出的衡量来说，零缺陷是很不划算的。理想状态下的测试系统，根据帕累托的二八原则，研发测试应该至少发现80%的bug，而最好只有5%的缺陷是由客户发现的。之所以要推行good-enough的原则，是因为在项目中时间、成本、质量是永远不可调和的矛盾，不论是高层还是基层的测试负责人，软件项目管理人员都需要对自己负责领域进行一定平衡和妥协。
　　总而言之，做好了测试的管理，对于软件项目的成本、工期和质量管理都有非常大的好处，但是目前国内的很多软件企业却不重视，特别是针对客户的定制项目，希望未来一段时间能够得到改观。

转载地址：