求教，如何规划测试组?

kpkp

目前我们测试组的地位比较特殊，它不是普通意义上的功能测试、验交测试（这个有另外的测试组去做）

我大概总结了一下，目前我们测试组做的是如下的事：
1. 测试环境的搭建与维护（单元测试、每日集成等）
2. 测试环境的使用和推广
3. 编写部分单元测试用例（更多用例推广开发人员自己写）、集成测试用例（这个是自己写）
4. 调试环境的搭建
5. 根据需要项目开发新的测试工具
6. 测试工具的使用和推广（自己写的工具、商业的工具）

现在老大要我给这个测试组进行定位，好规划未来工作的工作。
我初步的想法是把小组内的成员拆分成“测试开发工程师”和“测试工程师”，并总结了一些前辈处收集到的信息，初步整理规划如下：
1. 前面所说的第1、4、5点归到“测试开发工程师”的工作。更偏重于工具、平台的开发
2. 第2、3、6点归到“测试工程师”的工作。更偏重于平台工具推广，早期质量保证
3. 后期测试工程师可以更多的参与需求讨论、开发人员设计评审。把bug扼杀在萌芽阶段

现在有如下的问题请各位帮忙给点建议？
1. 是否应该把现在的测试组进行拆分，拆分成“测试开发组”和“测试组”呢？
2. 测试工程师的人数问题，由于是几条产品线同时工作的，如果给每条产品线都配置一些测试工程师，那峰值期间测试工程师的人力肯定不够。大量招聘？那项目发布后期维护阶段，又如何为这些测试工程师安排工作呢？
3. 关于绩效考核，“测试开发工程师”的工作是容易看到成果的，但“测试工程师”的工作是比较难看到成果的。那考核时该怎样评价“测试工程师”的绩效呢？

tengmy

个人的一点建议。
首先看你们的公司业务多少和规模大小。
如果公司不大，项目多变，常常有麻雀作战的测试情况。最好还是不要分组。
但是组内可以根据每个人的特长来大约的分出来他们主要负责的东西。
比如说，codi技能比较好而且比较擅长的，可以主要负责开发测试工具。至于环境搭建，单元测试以及其他这样的，看业务需要，可以并到之前的那批人中，也可以让所有的人都会。但是需要指派特定的负责人以及相应的backup。
如果公司测试人员少，适当招聘是必须的，但是招聘到的新人到培养成可用的人，需要一段时间。做好这个环节的事情，比如如何去带新人，让他们尽快的熟悉并且可用。
但是最好不要因为忙去招人，因为一旦项目变少，人员闲置，老大们怎么说呢？而且即便招人，最好根据之前的业务和以后新增的业务量以及它的延展性，考虑好后续人员的项目连续性，然后仔细评估好后，再去跟老大谈，招人，理由，自己期望的人数以及备选人大概的能力等等。
每个公司都会有业务间隔，做好这个时期的项目培训。总结上一个项目，项目里面的学到的东西，每个人的经验分享，每个人的技术能力不同，可以分享的东西就多了去了。然后尽早和公司高层以及开发项目组沟通，知道下一个项目的情况，好做新项目介入的前期准备。
关于考核
要让所有的人都很清楚一件事，所有的人都是测试人员而不是开发人员。所以衡量他们的标准一定是测试的标准。即便是开发测试工具的人，也不例外。
这样首先就杜绝了测试组内厚此薄彼的倾向。而且开发测试工具的人员也要时而刻意抽调出来做普通测试，普通测试人员要偶尔让他们有机会参与到开发测试工具中，即便不懂得code，研讨也好，或者提提意见，让他们过一把客户需求审核的瘾。
具体考核时：
测试业绩包括：开发的测试工具的质量；测试设计的质量，测试的过程以及监控效果，测试覆盖，测试执行的质量和数量，测试缺陷检出率以及优先级别，测试报告等（文档）的质量。间歇期间的培训参与程度，技能学习和自我改进以及乐意分享的意愿，工作的态度，沟通能力等等。

archonwang

。。。。
规划，始终是方向性选择的问题，

分不分组，取决于今后的发展，如果维持之前的项目情况，则应进行分组，人员对口，专业化发展；如果项目多变，个人觉得没必要增加内耗；

招不招人，看的是预算成本，不是看需不需要；为了将来长远打算，觉得太渺茫了，也许根本就不会获得认同；此外，团队规模膨胀会给leader带来巨大的负担；

客观点说，关于绩效，感觉没有比结果更重要的了。必要的基础数据（比如：漏测率、项目总体质量情况等等），个人成长始终是其次的——这和个人的诉求有关。

主观一些的话可以看看态度、沟通啥的，每个人的认知都不一样。