- 从一个故事说起 (本故事纯属虚构，供讨论和学习)
- 人物介绍
- 事件经过
- 实际情况文章源自玩技e族-https://www.playezu.com/214875.html
- 项目背景
- 团队配置
- 交付流程
- 反思和改进文章源自玩技e族-https://www.playezu.com/214875.html
- 用客观数据说话
- 进一步提高自动化测试覆盖率
- 划分清楚职责范围
- 避免情绪化回复质疑
从一个故事说起 (本故事纯属虚构，供讨论和学习)
人物介绍
- 阿科 - 一个测试负责人
- 阿花 - 一个技术 leader
事件经过
在一个非工作内容讨论的会议快结束的时候，不知道为何突阿花然扯到了测试人员的输出，绩效等问题。文章源自玩技e族-https://www.playezu.com/214875.html
- 阿花：你看我们开发测试比达到了 4:3，这个在行业算是行业高配了，我觉得你们测试效率不行，输出不够，我都不知道你们整天在干嘛
- 阿科（一脸懵逼）：因为项目历史原因，我们 UI 自动化测试覆盖确实不太高，但是最近 UI 自动化其实已经覆盖了大部分回归用例。并且 API 自动化也是一直有的，API 的回归测试结果我是定期在群里发送的，UI 的自动化回归最近也加了一部分了，我让阿西也每天发到群里。
- 阿花：反正你们团队整体输出不行，你要好好改想办法提高团队效率
- 阿科：好的，我们想法改进。我这边之前也是花了很多时间去维护 API 测试，包括维护测试数据，更新测试用例，补一些开发没有加的测试用例。
- 阿花：你不能因为维护了下 API 测试，就把这个输出算到你头上，这是开发做的！
- 阿科：。。。
- 阿科：我这边之前一直忙上线流程，包括性能测试那些，其实没有那么多时间参与自动化和功能测试那些
- 阿花：我不是说你要怎么怎么，你作为 leader 要考虑提高整个团队的效率和输出！
- 阿科：因为第一阶段测试是陆陆续续进来的，为了赶进度，自动化确实没跟上。你看，这是我正在写的流程文档，我们这边已经制定计划开始改进了
- 阿花：我不想看这些，我只看到有两个 automation QA 根本就没有 automation 的卡，你要想法让他们开始做一些具体的自动化任务，不能光是学习！
- 阿科：好的好的。。。
- 阿花：就这样吧，你多想想吧，你是 leader！你看需不需要专门开个 QA 的 retro meeting 不？
- 阿科：好的，好的，可以的。
实际情况
因为项目迭代周期快，早期测试资源不足，而且全是新功能，需求经常改，时常出现一张卡做了一半改需求，其实不太适合 UI 自动化。为了保证按时交付，无论是手动还是自动化测试都去做手动了。在早期时候更是如此，只有阿科一个测试，更是加班加点去完成测试任务。文章源自玩技e族-https://www.playezu.com/214875.html
- 因为没有明确说明 bug 数量是测试 KPI，测试这边提 bug 时候考虑到和开发大部分关系还是比较和谐的，很多时候没有专门建 bug 卡，或者为了提高效率几个 bug 合并到一张卡里面。这导致最后的 bug 统计报表并不能准确体现测试工作量，也不能准确度量软件产品质量。并且很多任务卡因为 bug 和需求改动导致测试多轮（三轮以上），这些数据都没记录和可视化出来。
- 同时，也没有明确说明自动化用例覆盖率/条数等是测试的 KPI，因此为了能够快速迭代产品，早期 UI 自动化也没跟上。但是 API 自动化测试基本是跟上的，并且到项目第一阶段快结束时候 UI 自动化已经覆盖回归测试了。
基于这两点，阿科在项目开始时候默认为保证产品按时高质量交付是最重要 KPI，这下突然来个灵魂三连问，把阿科整懵逼了。因为平时缺少一些记录，也没有更具体的数据和报表体现测试工作量和输出，这次只能是哑巴吃黄连了。文章源自玩技e族-https://www.playezu.com/214875.html
项目背景
这是一个在现有的一个平台上开发的一个全新业务，技术和架构上没有太大挑战，但是业务逻辑相对比较复杂，细节非常多。研发流程是敏捷开发模式，两周一个迭代，但实际上做了大半年才真正第一次上线，所以其实是一个大的瀑布流中嵌套的敏捷流程。很多业务只有到了后期才能串联起来测试，并且需求变化从头变到尾，也是进一步加大了后期测试的难度。整个项目最大的难点在于满足复杂的不断变化的业务需求。文章源自玩技e族-https://www.playezu.com/214875.html
团队配置
一共两个敏捷团队，每个团队由一个技术负责人 + 两个后端 + 两个前端 + 两个自动化 QA+1 个手动 QA+1 个 BA 构成，除此之外还有一个 scrum master，一共接近 20 人。因为两个团队是做同一个产品，并且产品是一个业务上耦合度比较高的产品，所以两个团队一起做的时候其实不太敏捷，因为需要不停的跨组交流，沟通成本还是挺高的。文章源自玩技e族-https://www.playezu.com/214875.html
交付流程
每个 sprint 完了会给客户 demo，demo 完成之后客户在一个集成环境在做一些验收测试。但是早起参与 demo 的客户很少，临近上线加入更多客户参与 demo，提出了更多不同想法，这也是导致需求变更原因之一。文章源自玩技e族-https://www.playezu.com/214875.html
反思和改进
情绪归情绪，冷静下来反思后，确实有需要改进的地方。
借用原则这本书上的一个公式。文章源自玩技e族-https://www.playezu.com/214875.html
痛苦 + 反思=进步文章源自玩技e族-https://www.playezu.com/214875.html
用客观数据说话
无论什么时候，测试团队应该客观记录下测试人员的工作量和产出数据。因为测试人员角色相比开发，比较边缘化一些，产品没有出问题，那是理所当然的测试指责，一旦出问题，首先被问责的肯定是测试。因此，无论是工作数据还是产品质量度量的数据，平时都应该记录下来，最后能用一个可视化的报表输出最好，并且定期和团队回顾，持续改进。质量和测试工作度量的方法论很多，这里不在展开说，结合这个故事来说， 最起码的测试提出的 bug 应该认真记录，并且应该打上对应的标签方便日后分析。即使没有提 bug 的 KPI，这也是测试日常工作的一个记录和产品质量分析的记录。还有每个功能点测试轮数也需要记录，一个功能如果反复修改还出现 bug 导致迭代周期延长显然不是测试的问题。
进一步提高自动化测试覆盖率
客观的说，对于需求频繁变化的新产品，自动化维护成本太高（特别是 UI 自动化测试），而且很多探索性测试场景难以覆盖。但是如果自动化覆盖太低，又会让项目后期背上很多技术宅。对于一个配置了专职自动化测试的项目来说，如果项目到后期需要短时间迭代上线，而这个时候没有配套的自动化测试用例，肯定会被质疑，并且也会影响产品上线周期。因此，对于新项目如果添加自动化测试，就的具体具体分析了。首先应该参考自动化测试金字塔模型，优先 UT，然后 API，最后才是 UI 自动化。如果一定要做 UI 自动化，从场景说应该优先覆盖稳定的 somke case，从框架层面说，应该根据项目需求搭好底层框架，完成好基本的底层框架后，后面基本就是添加元素定位配置和业务场景的搬砖工作。
划分清楚职责范围
如果不是测试团队的指责范围的工作，如果没有官方要求，没必要默默承担，职场是个用数据和事实说话的地方，默默承担的工作未必能获得所有人认可。
避免情绪化回复质疑
当阿科面对质疑的时候，第一反应是测试团队这么辛苦，为了按时保质让产品上线付出了很多，也默默做了很多工作，因此第一反应回复质疑的时候是有些情绪化的。如果没有具体的一些数据和事实作为支撑，特别是本身就是突如其来的一些质疑时候，避免情绪话回复，这样只会让对方也越来越情绪化，因为对方很可能也是因为情绪上的一些原因提出一些质疑（比如对方也面临外部或者高层压力）。面对这种情况，如果有数据和就用数据客观回复，如果确实是需要改进的问题，下来反思，讨论，总结，继续改进，如果既没有足够的数据，也不是自己团队的问题，那就听着么，谁都难免会有情绪，相互理解下，说完了回去该吃吃，该睡睡，过几天就好了。
下载功能测试 软件测试
评论