敏捷实践 敏捷测试还没有到来

作者 | 张大猫

01 背景

去年 10 月，ewaysun 找我加入「2021 年行业测试敏捷化年度报告」的调研，当时因为工作较忙，只是偶尔参与了一些讨论。一晃半年过去了，2022 年整个春夏似乎都在疫情中过去了，看到天气预报说出梅了，而淘宝上的衣服都已经开始出秋季款了。而我也从一个质量小团队的 team leader 成了一个质量大团队的 team leader。我还记得老板给我的寄语里有一句是：让团队成长为一只更加矫捷的团队——似乎正好对应了敏捷测试。文章源自玩技e族-https://www.playezu.com/180550.html

2007 年，我大学毕业，进了一家小外企在上海的 RD 做 Java 开发。当时我们采用的模式就是敏捷开发中的 scrum。文章源自玩技e族-https://www.playezu.com/180550.html

Scrum 是一种敏捷软件开发的方法学，用于迭代式增量软件开发过程。Scrum 不是一种过程，也不是一项构建产品的技术，而是一个框架，在这个框架里可以应用各种过程和技术。Scrum 是一个包括了一系列实践和预定义角色的过程框架。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个 Sprint，每个 Sprint 的建议长度是 1 到 4 周（也有的说是 2 ~ 4 周）。文章源自玩技e族-https://www.playezu.com/180550.html

那个时候，敏捷应该刚刚火热起来，大大小小的国内公司都在用这个模式。但是我印象只剩下每天的早会，从一开始的有模有样变成了最后的形式主义。文章源自玩技e族-https://www.playezu.com/180550.html

2009 年，外包去了谷歌做 DartEnterprise 的测试，在来福士的办公室体验了一段时间的谷歌环境，记忆最深刻的就是好吃好喝。我记得我们那个测试 team，没有什么固定的研发模式，现在回忆起来应该是螺旋模式。在工程师文化浓郁的团队里，充分的单测和 cr，以及 peer 测试带来了非常高的交付质量，记得当时有一个广告 inventory 系统，研发 cr 了 2 周左右，测试的时候发现不了缺陷，开发就搬了把椅子坐在旁边一起找问题，还有专门的 bonus 给测试。现在想想，对测试来说，真是非常理想的生存空间。文章源自玩技e族-https://www.playezu.com/180550.html

后来离开谷歌又去了一家做英语教育软件的外企，他们用的是 Scrum 白板管理和 BDD 驱动，所以又有了每天早上的晨会。我们的产品会把需求拆成一个个 story，然后研发把 story 一个个实现，测试就根据 story 编写测试用例，进行测试工作。再配合白板管理，形成了一个小而美的研测闭环。当时也用 cucumber+capybara 搞了自动化，效果还不错。文章源自玩技e族-https://www.playezu.com/180550.html

2014 年离开了外企，去了阿里。移动互联网兴起，从此中国互联网开始了大跃进。现在想想可能从那个时候起，互联网的生存环境就开始变坏了。互联网用的是什么模式？加班模式？

我收到《年度报告》之后，认真读了选项和案例分析，我在想是什么让测试开始了左冲右突，开始了全流程质量把控，质量效能度量？一方面是测试行业的逐渐成熟，另一方面也凸显了测试生存环境的日益恶劣。不求变则死。所以我们看到了各种方法论的问世，目前最流行的就是我刚刚说的，全流程，左移右移，度量。粗俗一点说就是卷别人和卷自己。文章源自玩技e族-https://www.playezu.com/180550.html

02 为什么要卷别人？

因为产品做的不好，研发做的不好，SRE 做的不够。文章源自玩技e族-https://www.playezu.com/180550.html

从市场到产品，从用户到产品，产品这个角色承担着最重要的解读职责。一个专业的产品能够将市场需求用户需求转化成技术人员能理解的需求文档，并根据专家经验和数据排出需求的优先级，如果有一定的研发背景，还可以在技术方案上给出一定的见解。这么多年，我见过的好的产品经理越来越少了，不过这个和我的立场有关系，毕竟测试和产品一直是相爱相杀的。

再说研发，虽然说单测，研发自测是行业共识，但是好像只是测试同学一厢情愿的行业共识。在我们的实际工作中，研发交付的质量往往比较糟糕，测试是测试同学的工作，这可能是研发的心里想法，常常听到研发的声音是开发都来测试了，那你们测试做什么？

最后说下 SRE，其实线上质量本来就应该测试和 SRE 共建的一个事情，只是侧重点不同，只不过当下的质量团队发展到最后往往成了质量效能风险团队，质量在右移的过程中，把技术风险和 SRE 也吃掉了。
图片

03 为什么要卷自己？

正如研发挑战的你们测试在做什么，你们有没有帮助业务？一个非生产力的角色要做到影响力其实挺难的。当我们看测试的工作，写测分，写用例，执行用例，报缺陷，写报告，这似乎更像是一个体力上重复工作。互联网上充斥着各种测试门槛低的说法，什么样子的人培训一下都能进这个行业，加上测试以外包公司为主，测试成了低级的工具人工种。我们看基本技能这一块，软技能成了最重要的，而软技能是最难量化和衡量的。前不久流行一些文章，说如何搞垮一个测试团队就是过度度量，也不是没有道理。

但是度量是一定要做的，所以必须把测试过程数字化和线上化，这一块也是最近两年的趋势。

度量不是为了度量而度量，而是要去反推质量，反推测试团队的能力升级。测试度量是研发度量的一环，测试提效是研发效能能否提高的重要一步。

04 敏捷测试还没有到来

我们看到当下的测试团队生存手段基本就是全流程质量管控，质量右移和左移，以及测试提效和度量。这些都是重流程和重文化建设的事情，投入成本大，见效慢。所以怎么敏捷的起来？除非质量文化已经非常成熟，基建十分完备，团队成员能力都非常好，那这个时候才能快起来，而在这些没有到来之前，敏捷的手段很可能就是加人和加班。

业务规模决定组织形态，当下 VUCA 的时代中，组织需要足够的灵活，才能支撑住业务。而能灵活的往往只有人本身。我依然记得当时在谷歌的时候，和主管 oneone，他说所谓敏捷，只有个人的能力上去了，个人足够敏捷，团队才能足够敏捷。所以，各位同仁，加油吧。当有一天，我们不需要加班，通过技术手段轻轻松松地完成测试工作的时候，那才是敏捷测试时代的到来。