广州软件测试交流会第六次沙龙案例分析总结[转载]

广州软件测试交流会：http://www.gztest.net

第二主题：软件项目管理与测试论坛

A公司软件外包项目的案例

　　这是一个ERP软件外包项目，客户是某国的一家著名的大企业。

　　客户要求的内容很多，也很严格，不仅要求使用指定的技术和工具，而且还自主开发了一个平台，要求在该平台上进行开发、测试；还有各种文档格式要求和技术要求；最重要的是要保证工期，一定要在4月内提供高质量的、完整的产品。

　　成立项目组

项目立项后，A公司在开发部、测试部抽调人手成立了项目小组。项目经理是一名在软件项目方面有多年开发经验的开发人员，但是，他是第一次带项目。

项目经理下设三个小组：（每一小组设置一名小组长，配备若干组员）

负责详细设计的DS小组（6名成员）

负责编程的PG小组（5名成员）

负责测试的PT小组（5名成员）

另还有一名用户参与需求的分析与确认。

项目计划

项目经理在被指定负责这个项目后，自行制订了以下项目进度计划，简单描述如下：

1) 5 月10 日 ～ 6 月1 日 需求分析
2) 6 月1 日 ～ 6 月25 日 系统设计，包括概要设计和详细设计
3) 6 月26 日 ～ 8 月1 日 编码
4) 8 月2 日 ～ 8 月31 日 系统测试
5) 9 月1 日 试运行

项目进度计划表

项目各阶段	计划执行时间	参与人员
需求分析和评审	5 月 10 日 ～ 6 月 1 日	项目经理、开发人员、用户代表
系统设计和评审	6 月 1 日 ～ 6 月 25 日	项目经理、设计人员
编码	6 月 26 日 ～ 8 月 1 日	开发人员
测试	8 月 2 日 ～ 8 月 31 日	测试人员
维护	9 月 1 日 试运行	维护人员

项目过程

在项目经理、详细设计DS小组及用户的参与下，按原订的计划完成了需求的分析工作，顺利进入系统设计的阶段，在 6 月 15 日 项目经理检查工作时发现，按此时的工作进度不可能如期完成系统设计的工作，但用户所要求的工期是不可能推迟的，项目经理在没有与测试组长讨论的情况下就决定缩短系统测试的时间，在系统设计阶段推迟了10天（ 7 月 5 日 ）才进入了编码阶段，为了保证工期，项目经理决定二个小组同时进行，并行工作。编码人员投入编码，而测试组成员同时编制测试设计书，并设计测试数据。

由于系统设计做得比较好，而编程人员的水平也比较稳定，编程人员按原计划所需要的时间内完成了任务，于 8 月 11 日 把第一版的程序提交测试人员及用户代表，此时离交货期只有20天的时间，为了赶进度，测试PT小组的组长最后只能通过加班加点和增加2名测试人员的安排来开展工作。

用户代表看了开发出来的测试版本后，提出需求变更要求，项目经理觉得需求变更对软件修改不大，没有与相关人员讨论，就直接让编程人员修改，并重新打包提交测试。

在测试的过程中，测试发现比较多的问题，其中关于用户易操作性方面的问题，与开发的意见相持不下，测试人员认为这些问题比较重要的且必需改，而开发人员则认为问题不大，用用就习惯了，最后，问题反馈到了项目经理处，项目经理为了能保证工期，赞同开发人员的意见，不需要修改。

由于测试的时间与工作量一开始就没有得到详细的评估，且测试人员对业务需求了解不深，测试过程并不顺利，从而导致测试时间没有得到很好的保证，不过经过大家的齐心协力，加班加点，在预定截止日期的当天，所有程序都开发完毕，测试完毕，只是还有很多问题和错误需要修正。

　　为了保证工期，项目经理决定暂时将把有问题的功能及问题隐蔽，将所有的测试报告中的“再确认”一栏填写上“OK”。项目经理提交所有预定提交的成果。同时，PG和PT人员仍在继续奋战。

　　一周后，用户发过来大量问题，绝大部分是易操作性的问题，还有小部分是功能没有达到要求。项目小组继续修正问题，一个月后，用户同意验收，项目终于结束了，项目小组才得以解散。

项目最终执行表　　

项目各阶段	计划执行时间	参与人员	实际完成时间	实际完成情况
需求分析和评审	5 月 10 日 ～ 6 月 1 日	项目经理 开发人员 用户代表	6月1日	按计划完成，顺利进入系统设计的阶段
系统设计和评审	6 月 1 日 ～ 6 月 25 日	项目经理 设计人员	7月5日	在系统设计阶段推迟了10天才进入编码阶段
编码	6 月 26 日 ～ 8 月 1 日	开发人员	8月11日	按原计划所需时间完成，但受设计阶段影响，完成时间顺延10天
测试	8 月 2 日 ～ 8 月 31 日	测试人员	8月31日	通过加班和增加人手来完成测试工作，但发现的部分问题没得到解决
维护	9 月 1 日 试运行	维护人员	9月30日	提交后用户不断反馈问题，问题解决后用户验收

 

　案例分析

1、  A公司的软件外包项目得到了用户的验收，请问此项目是成功还是失败？为什么？

 

2、  在我们的实际工作当中，经常会出现由于测试过程中发现问题，程序需要修改，导致项目或产品需要延迟发布，也经常会出现项目或产品发布后还会有问题，对于这些问题，请问您认为这是测试人员的责任吗？

 

3、本案例中在成本、进度、风险和质量方面主要存在着哪些问题？与测试人员密切相关的问题有哪些？

 

4、我们有没有办法去避免这些问题的发生？

 

 

  第六次交流会 第二主题的论点归纳

1、        项目已提交验收，但项目有延期且出现问题，问：此项止是否算成功？
1）        观点一：结合项目背景，站在商业利益的角度，此项目成功，因为项目已得到用户的验收，也就是说公司是能够收到项目款项，这个项目应该算成功的。
2）        观点二：站在质量和管理的角度，此项目失败，项目没有得到很好的计划与控制，项目也没有从用户的角度考虑问题，质量方面没有得到控制。后果是增加后期维护工作量，同时必将对公司的声誉造成不良影响。

2、        项目的延迟和发布后产生的质量问题，是不是测试人员的责任？如果不是，应该是谁的责任？
1）        项目的延迟和发布后产生的质量问题，完全不是测试人员的责任，这应该与项目经理有关系，是项目经理在整个项目的控制中没有做好。
2）        项目的延迟和发布后产生的质量问题，完全不是测试人员的责任，但应该是测试经理的责任，测试经理没有与项目经理协调好，没有主动安排测试人员尽早介入，造成测试人员非常被动。
3）        项目的延迟和发布后产生的质量问题，测试人员需要承担一点责任，主要是没有主动地了解项目的需求和进度，一直处于被动的角色，作为整个项目的一员，应该共同去承担这种责任。

3、        在本个案例中，主要存在哪些问题？
1）        测试人员没有在需求阶段介入，导致测试对需求理解不够；
2）        项目经理的管理经验比较缺乏，没有对项目作好评估，没有客观地做好项目计划和控制项目进度，即没有一个合格的项目经理；
3）        测试经理的主动管理意识欠缺，没有及时与项目经理了解其他小组的进度情况；
4）        项目的变更控制和风险计划没有做，需求出现变更时，没有得到有效的评估就草率修改；
5）        项目的管理流程不规范，没有根据实际情况及时调整开发模式，不应采用瀑布式开发。
6）        整个项目中缺乏了QA的角色，当出现对BUG有分岐时，没有客观的内部组织协调好；
7）        客户代表没有发挥好作用，在项目过程中没有过多的参与。
8）        没有赋予测试组相应的权利，对软件质量进行客观准确评测，项目质量和进度完全依靠项目经理一个人掌控，增加了项目失败的风险。

4、        测试人员是质量体系中，应该属于质量保证的角色还是保证质量的角色？两者有什么不一样？
测试人员永远不可能保证质量，测试人员只能做事后的质量保证，保证质量是整个企业的质量管理体系相关，与企业的软件过程成熟度相关。
测试属于质量控制（QC），关注结果的度量和BUG 的纠正；
相比之下，质量保证（QA）关注软件开发流程的制定和执行。
ＱＡ和ＱＣ都是质量管理体系中不可缺少的一环。质保流程需要根据测试结果不断改进，同时测试结果验证质保流程的有效性。