开始做主管之如何规范测试团队

概述：

当你来到一个项目不规范的技术团队，你会怎么处理呢？

1.存在问题：

1.1.流程不规范

没有需求评审和设计评审，需求经常是业务或者项目经理直接跟开发提，有时候开发自己都不明白需求，糊里糊涂地就要开发，也没有设计评审，开发想怎么设计就怎么设计，代码质量差。

有时候下游或者上游开发并没有接到需求，然后这边开发完给到测试，测试也一脸懵逼。

1.2.没有计划

上线时间不是根据开发和测试同学排期和评估来定，而是业务和项目经理说了算。开发完了就跟测试同学说一声，有这么个需求，这个需求今晚/这周上线，你测一下，好像测试是个很随意的工作，并且每个任务给过来都说是紧急需求，测试时间也是不够的，导致测试非常被动。

1.3.测试在项目中参与度低

很多时候没有需求评审，测试同学连业务是谁都不知道，经常是基于开发的讲解进行测试，写不写测试用例也是看自己习惯了，开发同学也不清楚测试同学要测什么，毕竟也没有时间进行测试用例评审(也没有人负责安排)。

1.4.缺乏沟通

没有每日站会或每周站会，开发和测试同学不会主动反馈进度和风险，即使是当前进度不理想的项目大家也都不提，即使要上线了没测完也不管，反正上线就完事，有时候项目经理会追问测试进度。

1.5.没有共享文档

所有的测试环境信息、数据库表字段信息、业务说明(包含业务流程、业务逻辑) 都是每个人自己保存着自己要用的，大家都不去维护一份公共文档。

1.6.没有输出

项目完成之后没有总结，出了线上问题大家也不会复盘，无论开发还是测试都没有整理业务文档、记录项目的习惯。

总而言之，就是十二分不规范。他们可能觉得，本来就够忙了，花时间整这些东西，不是更忙了吗。

殊不知因为流程的不规范，带来的是更低的研发效率和研发质量

2.问题改进：

2.1.测试进度及计划看板

可以在一份共享表格中维护，可以是在一块白板里用便利贴跟进，列出目前开发中的、已提测待测试的、测试中的、已完成的任务，并且标明计划提测时间、实际提测时间、计划上线时间等信息，方便管理测试计划和测试进度

2.2需求评审

产品提需求需要先评审，开发、测试、产品都需要参入，需要说明需求目的与背景

2.3.提测规范

达到提测标准时需要发送提测邮件给测试同学，说明改动范围、影响点、自测情况、单元测试覆盖率、开发人员等。

2.4.用例评审

中大型需求需要在测试前进行测试用例评审，相关的产品和开发都需要参与(开发可对P0的case评审，后面只需测试和产品即可)

2.5需求实例化

沟通需求时，测试同学可以将需求用各种形式表现，便于产品、开发之间沟通和确认细节。

梳理流程图：复杂的交互可以画流程图，方便后面的测试同学理解需求。

3.测试团队成长

3.1月度总结

每个月测试组内做一次总结，可以分享典型问题，可以提出一些大家觉得待改进的点，也可以随意吐槽。最后将大家提出的点整理好推动落地。

3.2项目总结

大项目上线后，组织相关同学进行总结，每个人分享觉得自己做得好和做的不好的地方，总结可以改进的点并推动落地。

3.3业务文档整理

一般需求上线后第二天比较空闲，这是整理业务文档的好机会，可以整理业务流程，或者相关的sql、操作文档、脚本等。

3.4业务分享

每周一个同学在组内做业务分享，可以不需要准备ppt，直接在白板上画，可以分享自己熟悉的一个业务，或者是这周接手的一个业务需求，达到组内知识共享的效果。

可能有同学会奇怪，为什么都是这么基础这么普通的东西，为什么不做自动化提升效率。

3.5学习分享&工具分享

可以对自己的学习方法、技术学习习惯分享，也可以对自己熟悉的工具框架分享

4.流程&方案&规范计划

4.1测试规范包括哪些内容

定义：测试规范就对软件测试的流程过程化，并对每一个元素进行明确界定，形成完整的规范体系。

实际：般来说，小的公司或不正规的公司都不会书写这个，它一般由测试经理来编写，估计一般的测试工程师接触较少，不太了解

软件测试规范一般来说描述的内容包括：测试目的、测试类别、测试过程、测试方法、测试用例、测试管理、测试文档、测试工具都要进行明确的描述。

测试规范包括：制定测试计划，编写测试用例，形成测试报告，测试总结及文档编写，编写用户手册

（1）测试计划规范：它包括测试计划模板的编写风格和测试计划的编写要求。如：测试进度估算、测试风险评估、测试人员安排和测试时间安排由什么来确定等等内容。

（2）测试用例设计规范：它包含了测试用例的模板编写和测试用例的设计要求。如：测试用例设计人员、测试执行时间、测试用例设计的优先级等等。

（3）测试工具使用规范：有了这个规范，测试人员就知道“项目进展”到什么程度，什么时候使用什么测试工具。个人建议：最好把测试工具配置部分的“注意事项”也罗列在里面。比如说使用LoadRunner做性能测试时，支持哪些常用的协议？使用那些脚本开发语言都写清楚。

（4）缺陷跟踪系统录入规范：主要是规范测试人员按照统一的要求递交缺陷到数据库。录入时，必须考虑缺陷录入的格式、录入的要素以及缺陷录入的“必填项”的要求等等内容。

（5）缺陷严重等级划分规范：有了缺陷严重等级的划分规范，测试人员、开发人员和其它项目组成员，对于测试缺陷就有了统一的标准，也不会因为某个缺陷由于严重等级的问题项目组成员争论半天，提高了测试效率。

（6）缺陷优先等级划分规范：优先等级规范的描述，有利于开发人员准确定位缺陷的优先等级标识，为开发人员修复软件缺陷和衡量产品质量提供参考。

（7）测试报告规范：它包括测试报告模板以及对测试报告编写的各种要求。

5.测试主管的职责

1.负责测试团队的建设和培训工作；

2.负责测试相关流程、文档模板的建立与维护；

3.编写测试计划、分配测试任务，测试评审，确保测试的顺利开展；

4.参与产品开发阶段的评审工作，从测试角度提出设计建议和要求；

5.关注测试过程问题并推动问题解决；

6.规范测试流程、带领测试团队进行性能、自动化等多维度工作；

7.解决测试工作种技术难题，持续优化提升团队测试效率；

8.负责和各部门间的管理协调和沟通工作；

6.测试把控风险的关键点

需求----->设计|①----->开发|②----->测试----->发布|③----->测试报告|④

①第一个把控接口,设计评审完成后,在用例评审阶段一定要细评, 反推出设计的全貌逻辑,以测试视角查缺补漏

②开发完成后,提供冒烟测试用例,以开发自驱动力避免在测试时流程阻塞,造成项目延期或测试同事的额外工作量,遇到冒烟不通过的,需要打回

③发布流程系统中,必须给出需求或bugfix发布的id,否则不予发布

④产出测试报告中,bug与用例比评估项目的整体质量情况,作为筛选优秀项目的数据依据