通过测试过程驱动开发过程

    测试工作做的久了，有时候会感觉测试工作比较被动。尤其是公司提出希望通过测试过程来推动研发过程的改进的想法之后，少量程序员的工作开始变得被动起来，有时会变成测试人员推着开发人员走。这种低效率在一段时间曾使测试人员相当沮丧。
    先来分析目前整个研发过程中存在的问题：
    （1）对于小项目来说，需求常常不明确，并且测试人员往往是在拿到测试程序之后才真正接触到需求。此时，部分测试人员缺少对需求质疑的精神，往往以系统开发成什么样子，需求就是什么样子。
    （2）少数测试人员提交了缺陷之后，在该缺陷被处理（fixed）之前，不关注该缺陷的 变化状态，仅仅就bug提bug，缺少推动bug修改对意识。
    （3）少数测试人员关注被项目经理拒绝修改或暂缓修改（Rejected、Reprieve）的主动性不够，有时候测试人员提交的bug确实存在，但因描述不清楚或重现不了被拒绝，但测试人员却缺少主动与项目经理直接沟通交涉的勇气。
    （4）少数测试人员在对bug进行回归测试验证时，验证不通过的问题，一律做重新打开操作（reopen）而不与相应的开发人员做前期沟通。对于部分问题来说，面对面对沟通会比通过TD沟通的效率高得多。
    （5）部分开发人员在内部代码测试标准欠缺的情况下，偷懒不做代码测试，其结果往往是内部测试升级包发布之后，要么数据脚本升级都通不过，要么进入功能模块就报错，或者基本功能点报错。
    （6）部分开发人员修改bug时，就bug修改bug，甚至调试过程中遇到的新的问题也不愿意修改，而是丢给测试人员去测试。名曰发现了就修改，没发现就算了。
    （7）少数项目经理在评审bug时，缺少对bug的把关环节，部分流转到开发人员手中才发现问题修改不了。
    （8）项目经理因为种种原因，不能够在当天评审完当天的bug，也因此影响到开发人员不能够及时了解个人所负责模块的质量状态，修改bug不及时。
    （9）由于研发过程或项目管理过程不成熟，内部测试升级包的发布规范性欠缺，导致不能够及时拿到测试包。
    下面来说这个“驱动”的问题。
    仅仅依靠测试人员来驱动开发人员，我想是远远不够的。因为驱动的动力不足，而且驱动力也不足。但是研发过程中，可以通过测试人员的驱动来推动项目进度。具体实施的时候，可以考虑下面的做法：
    （1）设定内部测试升级包提交的标准，在接受内部测试升级包进行正式测试之前，执行类似于冒烟测试做法的基准测试，并在第一时间将基准测试结果反馈给开发团队（当然，项目经理需要根据这个结果做工作绩效考核）。只有通过了基准测试的包才能够提交给测试团队，以此促进代码测试的质量。
    （2）在正式测试过程中，以演示系统功能、口头描述系统业务的考核方式，考察测试人员对系统业务的熟悉程度，促进测试人员深入理解需求。当然，具体操作时，并不一定以考核的名义进行，可以以业务培训、业务交流的形式进行。以此促进测试人员深入掌握业务需求。
    （3）将测试人员与开发人员结对，也就是说开发人员处理完了bug，并且测试人员对bug进行回归测试验证通过之后，问题才算解决。评估缺陷的处理效率时同时考虑开发人员和测试人员对因素，强调合作解决问题。当然，这个前提是需要项目组每天对结对的两个人的工作成果进行评估。到那个时候，会看到开发人员问测试人员要bug修改的情形。以此促进合作，减少工作过程中对对立和相互推诿。
    （4）将编译、打包的工作自动化，使生产内部测试升级包的工作在形式上不受人的因素对影响，在自动编译服务器上可以随时生产需要的内测版本。
    （5）当然，由于项目经理常常是开发人员出身，并且在开发过程中可能还担任具体的代码编写工作。这个时候就有必要引入第三种角色参与业务需求或功能设计上的争议处理的评审过程，避免项目经理即做运动员又做裁判员。