最近研发吐槽测试测不出问题，并列出了五月份测试情况，（研发测出的bug+运营测出的bug+产品测出的bug）/测试测出的bug约等于7/3。得到这个结果我很是震惊，这个比例太畸形了，7/3意味着测试大部分时间没有工作产出，这个比例映射出这样的心里“bug都是产品、运营找出来的，测试一定在划水！”。
备注：虽然bug数量不能完全代表测试工作情况，但硬要当成一个衡量指标其实也说得过去。
为证实数据的可靠性，我对5月份测试情况进行统计，统计结果为 3/7，与研发所说的7/3还是有一定误差的，误差为什么会这么大，问题出在哪里？
为分析原因，我找对口的研发、产品和运营进行了长谈，沟通出以下结果：
- 研发：“7/3的比例是个人感觉，没有真实地进行过统计！主要是因为在沟通群或者各种会议上看不到测试的身影，对测试的内容无感，比如上次迭代都不知道测了哪些东西”。
- 产品：“在测试前没有跟我沟通过，这块功能毕竟这么复杂”。
- 运营：“验收测试时发现的问题确实不少，感觉测试的工作不是特别给力”。
通过这次沟通，发现多方对测试工作都存成见，为什么会存在这种现象？为进一步剖析问题，我对测试外包的工作进行了整体复盘。原来该研发团队之前没有测试同学，当引入测试同学时，研发团队很容易保持旧有习惯从而忽视测试，好比大家上班坐地铁本不需要身份证，但疫情忽然严重起来，有关部门要求乘坐地铁要携带身份证，但是很多人保持旧有习惯会忘记带身份证。
在过去一个月里，研发流程采用“扁平快”风格，研发过程尽量减少文档、减少会议，减少沟通。这种节奏在人少时不会出现问题，人一但多起来就会出乱子！研发团队引入测试团队，若研发流程无文档无会议不沟通，任何一位测试都不可能配合得出色。所以这次的问题主要是沟通不充分，多方对新需求/迭代没有达成一致，测试做了很多工作，但研发团队无感知。
测试介入研发流程
如果一个研发团队没有对接测试团队的经验，那么在对接测试团队时要注意以下事项。
- 产品 在需求评审时拉测试同学，让测试同学对需求能够充分了解；参与评审测试用例，能够从产品视角给出建设性意见。
- 研发 在 系分评审 时拉上测试同学，让测试同学对本次迭代的主次功能进行充分了解；在评估上线时间时要考虑测试同学的测试时间，比如提取预留提测时间；参与评审测试用例，能够从研发视角给出建设性意见。（系分，全称为“系统设计、业务分析”）
上面两个要求对研发和产品提出的，小伙伴们可能会问：“若研发和产品之前没和测试对接过，他们根本不会遵守这个要求！”说的没错，既然研发团队不能，此时就需要测试同学要积极主动些，主动把产品和研发向合作方向上牵引，如何进行牵引呢？测试要知道研发流程是什么，下面给出一个简化版本的研发流程，大家可以用于参考：
- 需求收集：运营或者客户对需求进行阐述，产品进行需求收集。
- 需求评审：产品一般会拉各方开需求评审会，在这个会议上对需求进行宣讲，测试要充分利用这个会议了解需求是什么。
- 系分评审：确认本次迭代要上线哪些需求；本次迭代的重点功能是什么；需求提测时间、上线时间。
了解研发流程相当于了解每个角色的“作息”，下一步，测试要改变每个角色的“作息”，一般来说，测试要参与需求评审、系分评审、测试、上线四个阶段。在阶段开始前要做以下几件事：
- 需求评审阶段/系分评审阶段开始前：联系各方提前了解会议内容，比如在系分评审前要了解系分中提到的技术名词和核心链路，避免会上听不懂；提醒会议主持人按时拉测试入会。
- 测试阶段开始前：要与产品、研发、运营进行充分沟通，设计测试用例时要结合研发、产品、运营视角。
- 研发视角：本次迭代更改了哪些地方，这些地方需要进行回归测试；本次迭代新增了哪些接口，这些接口是否需要测试。
- 产品视角：有侧重地进行测试，关键需求要进行全面地测试，非关键需求的测试可以粗糙一下。比如A需求会影响用户使用，需要重点测试；B需求只修改了前端样式，可以简单测试。
- 运营视角：增加新需求要保障全链路逻辑正确，运营要明确哪些是全链路逻辑。
- 上线阶段开始前：向研发沟通变更风险点，上线前是否满足变更三板斧，本次变更的影响面。
小结
随着互联网工作压力增大，流程越来越趋向“扁平快”风格，研发过程尽量减少文档、减少会议，减少沟通。这种节奏在人少时不会出现问题，人一但多起来就会出乱子！研发团队引入测试团队会因缺乏沟通造成误解，此时就需要测试主动与研发团队建立联系。
测试陈(2022-07-11 22:02:04)
过于真实，工作中必要的沟通少不了