当前所在公司项目刚刚起步，感觉流程是一塌糊涂，这里讲一下人员配比，产品，开发，测试--1:5:1，基本流程如下。
- 产品经理写需求
- 需求写好后全体人员开会评审需求
- 开发进入开发阶段，测试继续测试之前的项目，目前阶段根本没有写用例
- 功能开发完毕，测试按优先级测试新功能
- 测试报告看时间，有空则整理
因为项目组人员有限，产品需求是项目经理兼职写的，人少活多的高负载下导致输出的需求也相对简单，有很多不明确的地方，而且由于需求写完不会发出来给大家，基本上都是周一例会上直接过需求，因此导致对需求完全不清楚，会上讨论功能时所有的注意都放在当前讨论的内容上，很少注意到需求上某些地方的不足，会议过后继续测试上一个功能也几乎没有时间再看新需求写用例，等功能上线后根据需求开始测试类似老徐说的核心功能点测试，这个时候多数问题才会暴露出来，需求上的不足，会议上没有讲清楚或者大家都认为清楚了实际上各自理解不同的地方，甚至有些功能因为任务分配不明确导致被开发人员忽略的都有。这个时候就出现了还没开始就卡住的情况了，十分影响效率，一两天过去了一个完整的功能可能还没有测完。要解决这种混乱就要严格把控流程，对比一下之前公司的流程，真心觉得上一家更加规范，效率也高。
上一家公司产品，开发。测试人员配比--2: 4：3
从人员配比上就能看出来产品开发测试人员实际上相差并不多，因此各方面相对当前公司也做的十分全面规范。
- 产品写需求
- 需求完成后分发给开发测试所有人员
- 召开需求评审会议，测试，开发均参加（负责人）
- 需求通过，测试编写更新测试用例
- 用例写完，进行测试用例评审
- 对评审中的问题用例进行更新
- 发版后进行测试，只需关注功能，UI的验收由产品负责
- 测试期间每天进行bug review，产品，开发以及测试相关负责人共同参加
- 对产品开发定义的非bug的问题在用例中说明
- 编写测试报告
总体来看比当前公司多了几点：第一，测试人员在需求评审前拿到需求可以对需求充分的了解，找到不理解存在歧义的点，也能找到一些需要补充的地方，这些可以再评审会中讨论确定，更好的为编写用例打好地基。同时也能提前找出一些测试需要开发脚本或操作命令支援的地方，让开发早早准备起来，节省了测试中先找的时间。第二、编写测试用例并评审，这使测试的任务更明确，覆盖度更广，没有测试用例仅靠需求文档很容易遗漏。第三、产品验收UI图，我觉得这个可能也是因为公司人手比较多吧，一般应该很少有产品验收UI的，但是感觉这个很好，产品经理对产品绝对的熟悉，明确知道自己想要的是什么样的效果，能更好的提高产品的可视度。第四、测试中每天的bug review，这个我觉得挺有必要提倡的，每天下午收尾前用10到15分钟的时间过一下一天的bug以及之前剩余的bug，首先可以确定bug能不能修复，哪个版本修复，其次将开发测试意见不统一以及开发won`t fixed的bug进行三方确认，明确需求，将bug打回测试关闭or打给开发解决，这样明确了要不要解决的问题，而且这样产品定义为bug并且开发负责人同意修改后比测试追着开发的效果好很多，再者就是通过bug的情况，使产品和开发对测试情况有了了解。
两个公司流程上的差距真的太大了，这种差距表现在了测试工作效率上。刚进新公司不久对整个流程有太多要吐槽的，吐槽过后就是切实的去解决这些问题，今天工作总结会议上提出了测试的问题，但公司是在人少事多，目前能落实的也只有对bug的系统管理，流程改革的路还很长，努力！
网友评论