撰写“我们项目两周后要发布新版本，现在QA忙不过来了，需要找个人帮忙回归。”
“这我恐怕搞不定！我还得花时间熟悉上下文。”
“你这么资深，我们都相信你肯定是没问题的。”
天啊！我可不是ChatGPT，怎么可能短时间内熟悉业务并能做好回归呢？别吓我！“团队其他角色帮忙回归更好吧！团队外的人就算再专业也不如团队内的人合适呢……”
千万不要惊讶，事实上，有着类似诉求的团队不在少数。面对这样的局面，该如何处理呢？
01 一个真实的故事
我前一阵接触了这样的一个团队：需要在5天内完成回归测试，但是QA还在忙着测新开发的Story，根本忙不过来。我尝试以外援身份从了解业务上下文开始去做回归测试，我知道这个方式行不通，不过是想了解团队更多情况，希望能够给他们一些切实可行的建议。
第一天
我是周三早上加入团队。早上10点，半个小时，PM给我简单介绍诉求上下文，QA告诉我要测哪些回归case。让我先自己熟悉系统，熟悉case，然后找BA给我介绍业务，因为QA还有其他会，还有正在开发的Story要跟。
我只好自己先熟悉。可是，BA一直也有各种会或团队内部其他沟通，而顾不上我。下午晚些时候，不能再这样等下去了，找BA要相对high level的业务介绍文档，想了解业务。先是给我一个当时迭代开发的业务文档，显然对我这个没有相关业务领域知识的人来说，太具体了，不能了解整个系统业务，我是没法做回归测试的。好不容易等到BA忙完各种会，给我发过来一份曾经的汇报材料，算是能满足我的需求。此时，已经晚上快七点了，我也不好意思让BA再给我讲，只好自己凑合先看看文档。
第二天
周四早上参加团队站会，了解到QA那天还有两个重要的Story要测，并且还有一个内部讨论会，她能留给我的时间非常有限。团队开发任务还挺重，其他角色也都很忙。
我只好根据前一天从BA给的文档里了解到的业务，以及在熟悉系统过程中跟QA确认过的一些点，自己摸索着开始回归测试。
回归测试case不算太多，对于一个熟悉业务的团队内QA，我估摸着一天测完没有问题。但是，对于我这个外援就不一样了，刚跑几个case就遇到了一些需要确认的问题……团队成员分散在不同地点，所以大家都是远程，这一点对于我这个新人外援尤其不友好，任何疑问我都得等QA（当时接触到的唯一合适人选）跟我确认。
就这样，我摸索着测试->遇到问题->等待确认->确认->继续摸索……一天下来，我也就跑完了十几条case。关键是这些我摸索着跑完的case，你能信任结果的准确性吗？实话说，我自己不能信任！
第三天
周五了，我前两天的工作几乎没有给团队带来什么价值，而且我不断找QA确认，应该给她带来不小的影响。我决定放弃回归了，停止在错误的方向上继续往前。
我把了解到的团队情况做了个总结，并附上我的建议。如下：
现状：
- 项目上没有BA讲解、也没有非常清晰的业务文档能够帮助外援迅速了解业务上下文；
- 回归测试case是从Story case直接拿过来的，缺少整合和维护，其中有些case还过时了，这让我这个外援无法按时高质地完成回归任务。
- 本次回归测试的工作量不算太大，项目上QA一天应该能够搞定。
建议：
- QA在周末加班一天完成这次的回归任务（后面可以调休），加班回归的效率会比平常效率更高，因为不会被其他角色或会议打扰。
- 整理业务场景，对关键的业务流程和角色进行简单介绍存档，有利于新人快速了解业务上下文。
- 按业务场景组织和设计专门用于回归的测试case（不能直接组合Story的case），并及时更新和维护，保持case的准确性。
- 将关键业务场景对应的回归case自动化，提高回归测试的效率。
- 找时间好好开个Retro，团队一起找出目前所有人都如此忙碌的根本原因是什么，并讨论出对应的改进举措。小心打着忙碌的旗号，一心闷头往前赶。
- 切记“团队为质量负责”，当QA忙不过来的时候，第一时间想到的应该是团队内部如何提供帮助，而不是求助外援QA。
周五下班前，跟PM和QA传达了我的建议，他们表示同意接受，让QA先加班看是否能完成回归测试，到下周一再看是否需要我更多support。
第四天
下一周的周一早上，PM告诉我QA真的一天就完成了回归测试，暂时不需要我了，他们会考虑我的其他建议，进行优化。
02 QA太忙的破局之道
每个团队有着各自的特点，QA忙不过来的原因也各不相同。通常来说，QA太忙可能是（但不限于）以下原因导致：
- 质量标准：对质量标准要求高，需要更多的测试工作来确保产品质量。
- 项目压力：如果项目进度紧张，测试周期短，QA可能需要加班加点来满足测试需求。
- 需求质量：需求分析做得不够，频繁的需求变更或需求理解不清晰，都会导致测试工作的不断迭代和增加。
- 缺乏必要的文档：需求文档、测试文档不完整或不清晰可能导致测试人员花费更多时间来理解需求和设计测试用例。
- 代码质量低下：低质量的代码可能导致更多的缺陷和频繁反复的测试工作。
- 缺乏自动化测试：全靠QA手动测试，导致测试工作量过大。
- 资源限制：人员不够、技能有限、硬件或软件资源受限，难以满足项目的测试要求。
- 测试环境问题：无法获得合适的测试环境或测试数据，延长了测试时间。
要打破这个局面，需要分析导致QA太忙的根本原因，综合考虑相关因素，找出合适的优化举措，如优化流程、提高自动化测试覆盖率、增加资源等。
可以参考下列文章，从全局的角度思考和找出破局之道：
- 构建测试的体系化思维（基础篇）
- 构建测试的体系化思维（进阶篇）
- 构建测试的体系化思维（高级篇）
- 敏捷测试的核心
- 测试左移
- 敏捷测试的指导性原则
- 说好的团队为质量负责呢？
- 团队对质量负责，“我”可以不负责？
- 软件测试中的『树莓酱定律』
- 软件测试中的『草莓酱定律』
- 一颗石榴给QA带来的启示
- 开发和测试融合：各尽所能，降本增效
03 磨刀不误砍柴工
“磨刀不误砍柴工”，相信大家对这句至理名言都非常熟悉。可是在日常工作中却很容易被交付压力所迫，只顾低头赶进度，而忘了回头看看是不是在正确的方向上，也不清楚自己所带的刀是否还能砍得动……
其实，当我们感觉到忙不过来的时候，一定是哪里不对了。这个时候急着赶进度，不如停下来，好好思考找出破局之道。不然，就会陷入死循环，只能是压力越来越大，导致越来越忙乱。
磨刀不误砍柴工，“刀”磨好了，自然会将忙乱扭转成忙而不乱。