Day 02 「住手！你想搞死 QA 吗？」 单元测试是测试还是功能？

今天在聊测试之前，我们要先聊 Scrum 与敏捷开发。为什麽？等会你就知道了。

烽火下的 Scrum

思考一下以下两句话：「我们这个 Sprint 先做功能，下个 Sprint 再补测试。」、「RD 这个 Sprint 先做功能，QA 下个 Sprint 再帮忙测试。」是否耳熟？是否是你自己也会考虑，甚至是经常做的事？

很多人号称自己在 Scrum，却忽略了一件很重要的事：Scrum 的 Sprint 产出物，要是「潜藏性可交付的产品增量（Potentially Shippable Product Increment）」。什麽意思？意思就是它不只要有增加新功能或修复，它还要是「潜藏性可交付」。也就是说，一个 Sprint 结束後，你的产品要保持在一个「不上线也行，要上线的话也随时可以」的状态。如下图所示，每个 Sprint 交付的产品，都要「可以交付」，这才是 Scrum 要的产品增量：

图片来源：https://community.atlassian.com/t5/Agile-articles/Scrum-Artifacts-with-pictures/ba-p/1265154

试想，如果你这个 Sprint 做的功能，下个 Sprint 才要测，不论那是自动还是手动，那你或你老板敢「随时上线」吗？我们就说一个 Sprint 是两周好了，老板一月想到的绝妙新功能，二月才能上线验证想法，到了那时，市场的最佳时机早就过了，那还敏捷个 P 啊？

「啊～ Scrum 没用啦～ 用了 Scrum 反而慢！」是不是很容易推导出这种结论？

哪有这种事？明明是你自己没有照人家 Scrum 规范，做出可交付的产品增量，哪能怪人家 Scrum 没有用呢？

烽火下的 QA

然而，如果老板还算理解 Scrum 的设计，真的要求要「可交付」，那第一个跳脚的就要是 QA 了。怎麽说呢？

笔者曾在国内培训名师 Joey Chen 的一场讲座上，听 Joey 举了一个非常贴切的例子，至今印象深刻：

就说你第一个 Sprint 做 10 个功能吧，那 QA 测 10 个不为过吧？如果 RD 输出速度很稳定，下个 Sprint 也做了 10 个功能，请问 QA 要测多少功能？

答案：20 个。因为你要回归测试啊！很快，5 个 Sprint 过去，RD 依旧每两周开发 10 个功能，老板很满意，但 QA 可惨了！他得测 50 个功能，而且以後还会越来越多！试问谁能不跳脚？这时试想，这些测试如果都能自动化，那测 5 个功能跟测 50 个，甚至是 500 个功能，时间上能差多少？总不会差超过 5 分钟吧？笔者曾经参与过一个有 1,500 个单元测试的专案，每次跑完全部测试也才 7 分钟。你上哪去找 QA 用这种速度帮你测？ 所以说为什麽我们要先聊敏捷开发？因为自动化测试才是敏捷开发的根本啊！

Joey 曾说：「没有自动化测试的敏捷，就只是在搞死 QA 而已。」

这不是开玩笑，这是真的。

自动化单元测试不是测试，是功能

没有人煮饭不试味道的，越是高级餐厅的大厨，越要试味道。不试，怎麽知道味道对不对？写程序也是一样，你不测看看，你怎麽知道你写的功能对不对？会说「没有时间写测试」的人，就是不把「试味道」当成做菜必要步骤的厨师。所以你估算时间时就要把「通过测试」列为完成条件，就像大厨估算料理时间时，不会漏了「试味道」这个环节一样。

「可是，时间就很短啊，怎麽办？」

你有两条路可以走：

1. 不要接这麽多单
2. 练习煮快一点

如果你短期内两件事都办不到，那你还可以这麽做：「检查看看厨房内的摆设或流程中，有什麽会造成你等待的，想办法解决它」，譬如：

1. 换一台三口炮炉
2. 一样的菜，一口气炒完再分装
3. 前一天把适量的肉拿来冷藏退冰
4. 搬动一下冰箱位置，让动线更顺畅

以此类推，你还有其他很多可以加速的方法。路是人走出来的，办法是人想的，但无论如何，身为大厨你就是不可以让客人吃到难吃的料理，不熟的更不行！就像无论如何你不可以让你程序的使用者整天在帮你抓 bug 一样。

世上有煮饭不试味道的人吗？有啊，路边摊的老板啊。路边摊嘛，一份餐点才收你那麽一点点钱，是要要求什麽？这时味道差一点无妨，客人也不在乎味道，你不要让他们等太久就好。

谜之声：「你觉得你是高级餐厅大厨，还是路边摊老板？」

Reference

1. Joey Chen 部落格：https://tdd.best/about/

tags: ithelp2021