测试主管如何扭临危受命，做正确的事

转自：http://www.ltesting.net/ceshi/ceshijishu/csgl/2008/0422/143779.html

我是在2006年5月到新单位工作的，新单位是一个很不错的单位，项目饱满，资金等方面也没有太多的问题，但就测试部门工作的情况却很不乐观。具体表现是人员少，任务重，人员不稳定。领导对测试部门的工作很不满意，在面试我的时候就多次表示了对公司目前测试不满，期待我来之后能够带领测试部门有一个比较好的发展。

        首先说说我们公司测试部门在这四个月的变化吧
        1 测试人员大量增加，原来的测试人员为3人，现在为14人，人员扩充了3倍，目前来说，测试人员的数量还不是很多，但相比原来部门的扩充速度还是很快的，另外一个方面，由于我们工作比较有成效，领导基本认可 开发 人员和测试人员比例可以达到1：0.8或1的比例。我想这个比例对一个国内的企业来说已经是很高的比例了。
        2 个人素质的提高。具体的个人素质提高不是很好说，还是用项目来说吧，我刚来的时候，测试人员在一个 系统测试 的时候，一般测试 需求 点位500个左右，后来一个项目在作 回归测试 的时候，测试需求点达到15000个，第二次回归测试的时候测试需求点达到了49000个，这里要说明的是，我们测试需求点的增加不是为了增加而增加，而是对被测试需求各种使用情况分析的更详细，程序覆盖强度越来越大的结果，测试发现的问题深度逐步增强的反应。
        3 机器设备的变化，测试人员是开发群体的弱势群体，他们的机器配置也是公司最低的，刚来的时候，全部测试人员都使用P4 1.7完全不能满足 自动化测试 的需要，目前，测试人员基本都是P4 3.0双核，液晶，测试人员很高兴。另外我们还有专门的 测试流程 管理 服务器 ，一些淘汰下来的老机器作为专门跑 测试用例 的测试专用机。
        4 开发人员对测试人员的态度改变。测试人员在开发过程中处于弱势地位，这是一个不可回避的现象，原来开发人员可以随意的让测试人员作自己认为需要的测试，而测试人员是没有办法拒绝的，甚至连具体测试的方法和手段开发人员都要干涉，而一旦出问题，首先怪罪测试人员，而不是找自己的责任，测试人员成了项目失败的替罪羊。而现在这种已经发生了很大的改变，至少测试人员有能力展示他们的特长。而不是开发人员的附属。
        5 领导对测试工作的态度转变
        我刚到单位的时候，领导们对测试工作很不满意，给我印象最深的是领导说，测试部门的工作人员，可用的就留下，不可用的就直接开除，这对测试人员的工作评价实在不高，现在好多了，首先测试部门现在的工作得到了领导的认可（原来我们总是被批评，而现在总是被表扬），其次，人员、设备的配置在增加，最重要的是，我们要求的测试时间可以得到保证。
 
 到单位工作4个月了，测试部门出现这么多的变化，有很多原因，但最重要的就是那句话：做正确的事情，正确地做事情。
        个人认为做正确的事情比正确地做事情要重要，道理很简单，中国的一句成语，南辕北辙是最好的解释了，如果不能了解什么事情是正确的事情，那么你做事情的效果越好，则整个项目失败的可能性越大。下边先说说我到单位做的几个事情。
1和领导达成一个协议
        和领导达成一个协议是一个很关键的事情，我在面试的时候，就了解到了领导们对测试部门的工作很不满意，希望很快扭转测试部门目前的工作状态，但一个部门工作状态的改变不是一件很容易的事情，在面试的时候，我就和领导们达成了一个协议，争取测试部门在3个月内有一个小变化，6个月内有一个大变化，12个月内形成一个良好的工作环境。领导是 一个明白人，没有强迫我在几天或几周内就要 有一个大变化，这为我们部门以后的发展打下了一个良好的基础。
2了解单位的工作情况
3了解单位工作的问题
4订立规则
5组建自己的团队以及核心团队
6协助其他人做工作
测试人员工作分配不均，严重影响工作情绪

   在我来的时候，测试人员都是被配置到项目组，开发人员有测试需求的时候都是直接找到本项目组的测试人员，由于各项目进度不一，造成在不同阶段测试人员的工作量严重不一，真是忙的忙死，闲的闲死。另外还有一个问题，有一些比较好的测试人员会主动帮助其他测试人员，而一些懒惰的测试人员作会坐在一边装作什么都不知道，结果是好的测试人员忙死，其他人闲死。


4订立规则

   在了解了测试部门当前的主要问题，解决的方法就确定了，具体方法：

A：首先是订立规则，说简单点先确定测试部门内部规则，我规定测试部门只接受系统测试，不接受 单元测试 和 集成测试 ，说简单点，测试人员进行的测试必须是一个完整的测试周期，最短时间是2周，这样才能保证测试工作的最低测试强度。

B：我向测试人员明确测试人员是软件开发过程中的专业技术人员，他们的特长就是 测试技术 ，在测试技术上测试人员不能比开发人员水平低，所以，他们的测试工作要保持自己的独立性，问题的发现是他们作主，至于发现的问题是否是BUG，是否需要修改，这是开发人员（确切的说是项目经理）和 质量保证 人员来确定，但是否是问题是测试人员来决定，测试人员判断是否是问题的标准就是测试结果和测试预期结果是否相同，只要不相同，就算问题。其他人员无权对这个原则提出异议。

C：为了保证测试的独立性，我要求测试人员在 测试过程 中，不要和开发人员有过多的交流，如果有交流也仅仅限制于关于系统如何使用方面（我们没有很好的开发文档），其他的一概不和开发人员讨论，这种方法虽然会对开发工作有一些阻碍工作，但在测试工作当时的工作状态下是很必要的，否则整个测试工作的独立性根本无法保持。

D：使用测试流程管理工具，我们原来的 测试计划 、测试用例都使用word文档来管理，很不方便，我来单位后，采用了专门的测试流程管理工具，也就是说一个完整的测试，首先写测试计划（主要内容是测试人员，系统需求，时间等方面的信息,这个东西还是使用word来编写），其次是测试需求点、测试计划（这个测试计划是我们测试用例执行的先后次序），每个测试用例的测试步骤，以及发现的所有问题。在最近的一段时间，通过 测试工具 的使用，使我们测试需求点的管理从不规范，随意写，到有条理，有顺序，有了很大的变化，我们的一个系统，在我来以前测试需求点大约是600个。在我们后来的几次回归测试中，测试需求点，分别为20000，500000，60000个，测试需求点的变化，说明了测试强度的增加和规范。

E：测试结果需求评审，否则不进行回归测试。这是一个原则问题，确切的说测试人员在开发过程中不能直接创造价值，他们的工作必须通过开发人员才可以得到体现。开发人员是否重视测试中发现的问题，是否对这些问题进行认真的评判和修改，不但关系到测试人员工作价值的体现，而且对测试部门工作安排也很重要。在我们测试的几个项目中，如果开发人员认真对待测试结果，一般来说，进行1到2次回归测试，整个系统 bug 就会呈现出收敛状态，否则，测试人员需要无休止的测试。在测试过程中，我一方面保证测试周期的时间的要求（最少2周）。一方面，和质量保证人员配合，对于那些不认真对待测试结果的项目组，采取不评审，就不进行回归测试的方法。（反正项目延期不是测试部门的责任，有点无赖，但有时候也是没有办法）。保证了测试的有效性。