软件测试管理浅谈

dangxinyan

   最近做了一个关于医疗方面的项目，测试阶段有幸担任leader，对软件测试有了进一步的了解，在此分享一下个人的体会，这是我第一次写技术日志，写的不好希望大家谅解。
    先说需求设计阶段，我们testing team 是从项目kick-off 阶段就介入的，与客户和开发组共同参与的需求的讨论，最后由我们testing team 完成需求文档的编写，然后是通过了内部评审和外部评审。在这个阶段我们对需求的了解，确认工作是经过一个个激烈讨论的会议达成的，会议的重要性不言而喻，因为我们介入这个项目的时候不管开发和测试对系统业务流程的了解全部为零，通过客户对我们的KT（Knowledge Transfer），开发和测试在需求的理解上达成一致，然后开发先给出开发计划，随后测试根据开发提供的开发计划制定测试计划，这个测试计划要在开发计划出来以后的两天内完成。这样我们测试和开发的工作基本做到并行进行。在这里我想说一下关于开发或者测试计划，当时开发提供的计划是只出一个Build，然后开发出最终版本以后我们测试组进行测试，但是客户不同意，客户当时Challenge开发组的leader，因为我们开发和测试是两个不同的外包公司，客户要分别支付我们effort，客户质问开发的，用三个月时间进行开发的话，那么这三个月测试组干什么？难道让测试的领钱吃干饭吗？开发的提出说，因为这个项目比较大，但是客户要求的时间却是非常的紧，如果中间出一个Build的话，要花费几天的时间去准备，比较浪费时间。对我们测试来说，如果进行这种方式的测试，在测试阶段我们的压力会特别大，时间比较段，工作量比较大，项目风险比较大。最后三方协调后决定是第一个月底由开发提供一个build，然后第二个build就是最终版本。这样虽然开发的浪费几天时间在build 1的发布上，但是对整个开发测试流程的掌控会更好，风险会降低很多。然后我们测试组出了一个和开发并行的测试计划。在build 1发布之前的二十多天时间里，我们不断的开会，确认需求，然后产出了需求文档和测试用例。关于需求文档和测试用例，我觉得我们的分工比较好，首先由三个老员工带三个新员工，分成三个组，然后三个组根据开发提供的系统的draft ，每个人分配了七个模块，各司其职，各组完成各组的需求和测试用例文档，完成以后，交叉评审，然后在进行组外评审。
在此要说的是，整个项目Build 1进行完以后，我们对Defect进行分析以后发现，在需求阶段，如果对需求进行更好的确认和管理的话，我们后期的Defect可以减少一半左右，可见需求的重要性。
    记得我最早接触软件测试的时候，一位老员工给我们进行了十天的软件工程培训，那时候他就特别提醒我们要重视需求，因为在软件开发测试过程中，需求是主线，所有的开发测试过程都是围绕需求这条基线进行的。
    未完待续……

dangxinyan

这里要提下版本控制了，尤其是offshore项目，版本控制尤为重要，因为客户对进程的了解和控制都需要版本，比如QC,VSS,或者有些公司自己开发的内部工具.我们知道在项目中change是随时可能发生的，有可能是天天发生，对change的控制就由测试来做，更新文档，更新case，随时跟新QC,或者VSS里面的文档，避免客户看到的信息是延迟信息。

dangxinyan

整个项目的需求文档最终发给客户review的版本是由测试开发的，因为正规的开发测试流程是客户和开发以及第三方所有的活动都要经过测试，不然到时候的权责问题是和测试无关的。

无法悟空

测试组也要写需求文档？测试组不是只需要针对研发的需求规格说明书出测试用例就行了吗？
新手，请指教、谢谢！

dangxinyan

因为我们要进行需求文档和测试用例的编写工作，但是在开发组开发的Build 1都是一些主要的功能模块，这些功能模块的需求都是确认的，而且Build 1给我们测试的模块仅仅是整个系统的三分之一，所以他们开发的都是已经确认的系统模块，我们要兼顾整个系统。不知道这样的回答合适吗？

dangxinyan

第一次发表帖子都没人顶，我自己顶了，fighting......