• 从一个故事说起 (本故事纯属虚构，供讨论和学习)
  • 人物介绍
  • 事件经过
• 实际情况
  • 项目背景
  • 团队配置
  • 交付流程
• 反思和改进
  • 用客观数据说话
  • 进一步提高自动化测试覆盖率
  • 划分清楚职责范围
  • 避免情绪化回复质疑
• 补充和更新（九月一号）
  • 项目背景信息补充
  • 进一步思考
  • 再进一步思考

从一个故事说起 (本故事纯属虚构，供讨论和学习)

人物介绍

• 阿科 - 一个测试负责人
• 阿花 - 一个技术 leader

事件经过

在一个非工作内容讨论的会议快结束的时候，不知道为何突阿花然扯到了测试人员的输出，绩效等问题。

• 阿花：你看我们开发测试比达到了 4:3，这个在行业算是行业高配了，我觉得你们测试效率不行，输出不够，我都不知道你们整天在干嘛
• 阿科（一脸懵逼）：因为项目历史原因，我们 UI 自动化测试覆盖确实不太高，但是最近 UI 自动化其实已经覆盖了大部分回归用例。并且 API 自动化也是一直有的，API 的回归测试结果我是定期在群里发送的，UI 的自动化回归最近也加了一部分了，我让阿西也每天发到群里。
• 阿花：反正你们团队整体输出不行，你要好好改想办法提高团队效率
• 阿科：好的，我们想法改进。我这边之前也是花了很多时间去维护 API 测试，包括维护测试数据，更新测试用例，补一些开发没有加的测试用例。
• 阿花：你不能因为维护了下 API 测试，就把这个输出算到你头上，这是开发做的！
• 阿科：。。。
• 阿科：我这边之前一直忙上线流程，包括性能测试那些，其实没有那么多时间参与自动化和功能测试那些
• 阿花：我不是说你要怎么怎么，你作为 leader 要考虑提高整个团队的效率和输出！
• 阿科：因为第一阶段测试是陆陆续续进来的，为了赶进度，自动化确实没跟上。你看，这是我正在写的流程文档，我们这边已经制定计划开始改进了
• 阿花：我不想看这些，我只看到有两个 automation QA 根本就没有 automation 的卡，你要想法让他们开始做一些具体的自动化任务，不能光是学习！
• 阿科：好的好的。。。
• 阿花：就这样吧，你多想想吧，你是 leader！你看需不需要专门开个 QA 的 retro meeting 不？
• 阿科：好的，好的，可以的。

实际情况

因为项目迭代周期快，早期测试资源不足，而且全是新功能，需求经常改，时常出现一张卡做了一半改需求，其实不太适合 UI 自动化。为了保证按时交付，无论是手动还是自动化测试都去做手动了。在早期时候更是如此，只有阿科一个测试，更是加班加点去完成测试任务。

• 因为没有明确说明 bug 数量是测试 KPI，测试这边提 bug 时候考虑到和开发大部分关系还是比较和谐的，很多时候没有专门建 bug 卡，或者为了提高效率几个 bug 合并到一张卡里面。这导致最后的 bug 统计报表并不能准确体现测试工作量，也不能准确度量软件产品质量。并且很多任务卡因为 bug 和需求改动导致测试多轮（三轮以上），这些数据都没记录和可视化出来。
• 同时，也没有明确说明自动化用例覆盖率/条数等是测试的 KPI，因此为了能够快速迭代产品，早期 UI 自动化也没跟上。但是 API 自动化测试基本是跟上的，并且到项目第一阶段快结束时候 UI 自动化已经覆盖回归测试了。

基于这两点，阿科在项目开始时候默认为保证产品按时高质量交付是最重要 KPI，这下突然来个灵魂三连问，把阿科整懵逼了。因为平时缺少一些记录，也没有更具体的数据和报表体现测试工作量和输出，这次只能是哑巴吃黄连了。

项目背景

这是一个在现有的一个平台上开发的一个全新业务，技术和架构上没有太大挑战，但是业务逻辑相对比较复杂，细节非常多。研发流程是敏捷开发模式，两周一个迭代，但实际上做了大半年才真正第一次上线，所以其实是一个大的瀑布流中嵌套的敏捷流程。很多业务只有到了后期才能串联起来测试，并且需求变化从头变到尾，也是进一步加大了后期测试的难度。整个项目最大的难点在于满足复杂的不断变化的业务需求。

团队配置

一共两个敏捷团队，每个团队由一个技术负责人 + 两个后端 + 两个前端 + 两个自动化 QA+1 个手动 QA+1 个 BA 构成，除此之外还有一个 scrum master，一共接近 20 人。因为两个团队是做同一个产品，并且产品是一个业务上耦合度比较高的产品，所以两个团队一起做的时候其实不太敏捷，因为需要不停的跨组交流，沟通成本还是挺高的。

交付流程

每个 sprint 完了会给客户 demo，demo 完成之后客户在一个集成环境在做一些验收测试。但是早起参与 demo 的客户很少，临近上线加入更多客户参与 demo，提出了更多不同想法，这也是导致需求变更原因之一。

反思和改进

情绪归情绪，冷静下来反思后，确实有需要改进的地方。
借用原则这本书上的一个公式。

痛苦 + 反思=进步

用客观数据说话

无论什么时候，测试团队应该客观记录下测试人员的工作量和产出数据。因为测试人员角色相比开发，比较边缘化一些，产品没有出问题，那是理所当然的测试指责，一旦出问题，首先被问责的肯定是测试。因此，无论是工作数据还是产品质量度量的数据，平时都应该记录下来，最后能用一个可视化的报表输出最好，并且定期和团队回顾，持续改进。质量和测试工作度量的方法论很多，这里不在展开说，结合这个故事来说， 最起码的测试提出的 bug 应该认真记录，并且应该打上对应的标签方便日后分析。即使没有提 bug 的 KPI，这也是测试日常工作的一个记录和产品质量分析的记录。还有每个功能点测试轮数也需要记录，一个功能如果反复修改还出现 bug 导致迭代周期延长显然不是测试的问题。

进一步提高自动化测试覆盖率

客观的说，对于需求频繁变化的新产品，自动化维护成本太高（特别是 UI 自动化测试），而且很多探索性测试场景难以覆盖。但是如果自动化覆盖太低，又会让项目后期背上很多技术宅。对于一个配置了专职自动化测试的项目来说，如果项目到后期需要短时间迭代上线，而这个时候没有配套的自动化测试用例，肯定会被质疑，并且也会影响产品上线周期。因此，对于新项目如果添加自动化测试，就的具体具体分析了。首先应该参考自动化测试金字塔模型，优先 UT，然后 API，最后才是 UI 自动化。如果一定要做 UI 自动化，从场景说应该优先覆盖稳定的 somke case，从框架层面说，应该根据项目需求搭好底层框架，完成好基本的底层框架后，后面基本就是添加元素定位配置和业务场景的搬砖工作。

划分清楚职责范围

如果不是测试团队的指责范围的工作，如果没有官方要求，没必要默默承担，职场是个用数据和事实说话的地方，默默承担的工作未必能获得所有人认可。

避免情绪化回复质疑

当阿科面对质疑的时候，第一反应是测试团队这么辛苦，为了按时保质让产品上线付出了很多，也默默做了很多工作，因此第一反应回复质疑的时候是有些情绪化的。如果没有具体的一些数据和事实作为支撑，特别是本身就是突如其来的一些质疑时候，避免情绪话回复，这样只会让对方也越来越情绪化，因为对方很可能也是因为情绪上的一些原因提出一些质疑（比如对方也面临外部或者高层压力）。面对这种情况，如果有数据和就用数据客观回复，如果确实是需要改进的问题，下来反思，讨论，总结，继续改进，如果既没有足够的数据，也不是自己团队的问题，那就听着么，谁都难免会有情绪，相互理解下，说完了回去该吃吃，该睡睡，过几天就好了。

补充和更新（九月一号）

文章标题可能给大家造成一些误导，这篇文章目的不是真的要大家和开发或者别的角色搞对立，动不动就上纲上线的，更多的是关于反思和改进，作为不同角色应该怎么更好的合作。

今天过来看看 testerhome，没有想到大家讨论这么热烈（比之前一些技术文章火多了。。。），还有些评论都看不到了。首先特别感谢一些同学给出了很多中肯的建议，但是由于这个故事背景信息给的不够多，导致同学们在一些点可能有些争议，我就再补充一些背景和信息。

项目背景信息补充

• 这是一个甲方项目，人员配置是按照甲方一个 team 标准配置来的，十几个敏捷团队都是这个配置。4:3 比例确实很高，是因为甲方对 UI 自动化有比较高要求，并且项目刚开始时候不是 4:3，而是 4:1，5：1 这样一个比例，测试是逐渐到位的。
• 有评论说阿科更多应该是保证团队输出，而不是很多事情亲力亲为。但是阿科在甲方的角色就是一个高级自动化工程师，角色定义也是主要负责 UI 自动化这一块（API 测试在甲方是分到开发侧的，测试主要负责 review），和团队另外几个自动化测试角色一样的，而手动测试更多的承担质量保证角色，并且手动和自动化两个团队在甲方是两条不同汇报线。所以一些具体的技术工作还是要做的。而所谓的测试 leader 只是乙方给的一个角色，希望能够有个角色全局保证产品交付和协调测试资源，阿科也是愿意主动承担这个角色，所以阿科其实比本身的这个角色承担了更多责任。简单说就是既要全局的看产品交付以及和测试团队同步，同时也要完成自己的一些任务，有时候只能靠加班。
• 接着第二点补充，自动化测试这边是有专门 team leader 的，阿科也定期回去和 leader 做一些同步，也邀请阿花的，但是阿花基本不参加。阿花的角色不是老板，平时也没有明确说明需要给他汇报工作。
• 因为是甲方项目，阿科一直把乙方的阿花也当成自己人，并且定期团队都会有各种各样内部的回顾和总结会议，通常情况大家都会把问题公开透明提出来讨论并提出改进措施。并且还有每日的站会，所有人也会参加，每个组员也会总结前一天工作和当天工作计划，所以当花突然提出各种质疑时候，阿科会一片懵逼。这也是为什么阿科推测对方当时可能有些情绪化的原因之一。
• 有评论提到没有看到保护测试团队。第一是当阿花是带有一些情绪化东西质疑时候，这个时候其实不是有理必争的时候，这好比你老婆生气的时候你却要和她讲道理。其实后来阿花私下又提到这个事情，说当时这么说也是更多为了帮助测试改进，没有别的太多意思。第二是前面已经提到的需要改进的事情，就是测试团队平时没有留下足够的数据最为一个支撑。
• 不是所有开发或者 leader 都质疑测试工作，其实还有阿虎阿轩。。。（包括一些 leader）都是很认同测试工作的，时常提到测试这边检查很细致。这也是前面提到的为什么测试开发关系其实总体比较和谐。
• 因为没有分支发布策略（用的 trunk-based 策略）和发布版本和专门测试环境，也是导致测试难度加大的一个因素。

进一步思考

如果反过来阿科作为开发，应该怎么更好和测试或者别的角色合作呢？

• 有问题尽早的明确的提出来，没有必要拖延掩盖。
• 尽量以事实作为依据，针对问题讨论，而不是针对人。
• 避免情绪化讨论，如果因为自己被老板问责心情不太好，等稍微冷静下来再讨论
• 重在改进而不是追责。
• 注意说话方式，比如这个故事这样开头就好多了：我觉得你们测试最近真的挺辛苦的，经常加班加点保证产品交付，我们要不要一起来看看我们整个流程还可以怎么优化？我们开发还可以配合你们做些什么？争取做到大家都 955，你看行不？ 如果这样开头，后面恐怕就是另外一个故事了。

再进一步思考

无论在什么公司做什么项目，都会遇到各种各样的问题，可能是技术问题，可能是非技术问题，总之问题是永恒存在的，并且没有办法解决完的，更麻烦的是如果不觉解决，问题还会越来越多。因此我们只能不断发现问题，排出优先级，一个一个解决，保持一个持续改进的状态。
希望和各位 testerhome 同学共勉。

先写到这吧，成都今天静态管理了，希望能早日恢复正常～