大家好，又见面了，我是你们的朋友全栈君。
前言：今天是2021年11月17日，我入职新公司工作的第20天，工作也确实比较忙，准确的来说在公司大家都忙，我基本上都是早上7点半起床，晚上12点到家，睡午觉的时间忙中偷闲更新下博客！
作为测试负责人如何规范测试团队？- 一、我的提问
- 二、你会发现存在的问题
- 1、流程不规范
- 2、缺乏沟通
- 3、没有共享文档
- 4、没有输出
- 三、如何做好流程规范
- 1、测试进度及计划面板
- 2、技术评审
- 3、提测规范
- 4、测试用例评审
- 四、如何做好需求把控
- 1、需求实例化
- 2、组内需求沟通
- 3、快速确认测试点
- 五、完整的测试流程
- 1、测试用例
- 2、提测
- 3、测试
- 4、上线
- 六、如何促进团队成长
- 1、月度总结
- 2、项目总结
- 3、典型问题学习分享
- 4、典型问题学习分享
- 5、业务分享
- 七、最后说说我的想法
- 1、自动化不是万金油
- 2、组织目标要基于当前矛盾
- 1、流程不规范
- 2、缺乏沟通
- 3、没有共享文档
- 4、没有输出
- 1、测试进度及计划面板
- 2、技术评审
- 3、提测规范
- 4、测试用例评审
- 1、需求实例化
- 2、组内需求沟通
- 3、快速确认测试点
- 1、测试用例
- 2、提测
- 3、测试
- 4、上线
- 1、月度总结
- 2、项目总结
- 3、典型问题学习分享
- 4、典型问题学习分享
- 5、业务分享
- 1、自动化不是万金油
- 2、组织目标要基于当前矛盾
一、我的提问
当你来到一个项目不规范的技术团队，你会怎么处理呢？
二、你会发现存在的问题
1、流程不规范
很多时候没有需求评审，测试同学连业务是谁都不知道，经常是基于开发的讲解进行测试，写不写测试用例也是看自己习惯了，开发同学也不清楚测试同学要测什么，毕竟也没有时间进行测试用例评审(也没有人负责安排)。
2、缺乏沟通
没有每日站会和每周站会，开发和测试同学不会主动反馈进度和风险，即使是当前进度不理想的项目大家也都不提，即使要上线了没测完也不管，反正上线就完事，有时候项目经理会追问测试进度。
3、没有共享文档
所有的测试环境信息、数据库表字段信息、业务说明都是每个人自己保存着自己要用的，大家都不去维护一份公共文档。
4、没有输出
项目完成之后没有总结，出了线上问题大家也不会复盘，无论开发还是测试都没有整理业务文档、记录项目的习惯。
总而言之，就是十二分不规范。他们可能觉得，本来就够忙了，花时间整这些东西，不是更忙了吗。
殊不知因为流程的不规范，带来的是更低的研发效率和研发质量。遇到这些问题，可以从哪些方面进行改进呢？
三、如何做好流程规范
1、测试进度及计划面板
可以在一份共享表格中维护，可以是在一块白板里用便利贴跟进，列出目前开发中的、已提测待测试的、测试中的、已完成的任务，并且标明计划提测时间、实际提测时间、计划上线时间等信息，方便管理测试计划和测试进度。
2、技术评审
中大型项目在开发之前需要有技术评审，各端开发都需要参与，尽量避免由一个人决定怎么开发就怎么来。
3、提测规范
达到提测标准时需要发送提测邮件给测试同学，说明改动范围、影响点、自测情况、单元测试覆盖率等。
4、测试用例评审
中大型需求需要在测试前进行测试用例评审，相关的产品和开发都需要参与。
四、如何做好需求把控
1、需求实例化
沟通需求时，测试同学可以将需求用各种形式表现，便于产品、开发之间沟通和确认细节。
梳理流程图：复杂的交互可以画流程图，方便后面的测试同学理解需求。
2、组内需求沟通
如果是由几个测试同学跟进的大需求，在大家看了需求文档之后安排个小会议室，大家一起头脑风暴一下，由一个人先主讲整个过程，然后其他同学进行补充和提问，达到快速学习和掌握需求的效果。
3、快速确认测试点
如果是时间紧迫的需求，可以几个测试同学到一个小会议室，结合代码改动点快速确认当前实现是否符合目标，是否有逻辑问题，然后结合需求和改动点快速梳理测试点。
公共点整理：各个重要的模块注意事项和踩坑点汇总成一份各模块checklist，下次测该模块的同学就能尽量少踩坑。
总之，就是发挥主观能动性，有什么好的实践可以帮助提升测试质量和提高测试效率，就可以去做，最重要的是及时沟通。
五、完整的测试流程
1、测试用例
- 需求评审和技术评审后准备冒烟测试用例和需求测试用例，都需要提交到对应项目版本迭代的TAPD中
- 用例中需明确优先级，无法测试的场景需要及时沟通
- 大需求需要组织产品和开发一起进行用例评审，小优化和产品、开发过一遍测试点即可，用例评审之后有修改的地方需要及时同步给相关人员
- 冒烟测试用例需要及时给开发作为自测用例
2、提测
- 需求和优化需以开发同学提测邮件为准
- 确认该需求涉及到的DDL（加表和字段）和DML（增删改数据）脚本是否有遗漏
- 确认代码是否正确提交
- 确认是否有修改配置文件，若有需开发提供正确的配置文件
3、测试
- 提测后先进行冒烟测试，冒烟测试通过率小于90%时提测打回
- 执行用例时按照用例优先级进行执行
- 不确定是否是代码问题的，需与开发沟通后，确定是问题再提交到TAPD
- 当天测试情况需邮件同步给相关人员，比如当前进度、待解决问题、待协调问题、风险等
4、上线
- 跟进上线情况，如有线上问题及时跟进，并记录到对应的线上问题文档中
- 上线后补充相关业务文档（需求背景、功能介绍、业务流程、系统交互、操作指引、业务规则、注意事项、涉及的表），测试过程中遇到的典型问题记录
- 结合迭代功能持续完善造数据脚本和自动化和自动化测试脚本（不限于接口自动化、UI自动化）
六、如何促进团队成长
1、月度总结
每个月测试组内做一次总结，可以分享典型问题，可以提出一些大家觉得待改进的点，也可以随意吐槽。最后将大家提出的点整理好推动落地。
2、项目总结
大项目上线后，组织相关同学进行总结，每个人分享觉得自己做得好和做的不好的地方，总结可以改进的点并推动落地。
3、典型问题学习分享
在月度总结里一起，需要大家提前将各自要分享的问题记录到统一地方，可以是测试中遇到的典型问题或者线上产生的问题。
4、典型问题学习分享
一般需求上线后第二天比较空闲，这是整理业务文档的好机会，可以整理业务流程，或者相关的sql、操作文档、脚本等。
5、业务分享
每周一个同学在组内做业务分享，可以不需要准备ppt，直接在白板上画，可以分享自己熟悉的一个业务，或者是这周接手的一个业务需求，达到组内知识共享的效果。
可能有同学会奇怪，为什么都是这么基础这么普通的东西，为什么不做自动化提升效率。
七、最后说说我的想法
1、自动化不是万金油
自动化并不是解决所有问题的万金油，为什么要自动化，当然是到手工测试效率阻塞测试进度的阶段，才需要通过自动化提升测试效率。
而想要提升效率，应该是先文档化，将知识沉淀下来，然后是脚本化，将重复性的工作自动化，最后是结合基础脚本实现平台化。
一上来啥也不管就想用自动化测试平台完成自己的KPI并不是一个理智的想法。
2、组织目标要基于当前矛盾
我认为组织目标是要基于当前的矛盾的，每个阶段有每个阶段的矛盾，每个团队当前面临的问题不同，比如需求不清晰、 测试环境不够用、测试环境不稳定、造数据效率太低啦等等。
那么我们要做的就是基于这些问题一个个推进解决。所以不是在任何情况下都是测试框架测试平台才显得高大上，特别是面对流程不规范的团队，把这些基础的流程做好，就能大大提升大家的工作效率了。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/127823.html原文链接：https://javaforall.cn
