场景还原：有人在群里抛出了这么一个问题：团队现在交接一个老系统，原来是给开发的，现在由内部团队接手，现在突然要快速迭代（大多是之前功能的修补），开发都不怎么了解里面的逻辑，经常是改一个点影响了全局。在测试人员和时间都非常紧张的情况下，怎么保障上线质量？
这是一个在小团队里经常会面临的场景，时间紧，任务重，客户催的急。很多时候面试官也喜欢问这种场景题（请做个合格的面试官吧…）。单从个人，或者从测试这个角色出发，能做的事情好像很有限，无非就是理清需求，加班测试，线上问题学会甩锅（保护自己）.好像也没什么不对，多数人也是这么过来的。在没有质量内建的思维下，也没什么灵丹妙药，否则现在国内的软件测试环境也不会是这个样子。
跳出测试角色，从项目的整体上来思考，主要有3个问题需要先梳理清楚：
团队目标：是不是所有人都觉得我们必须把这个项目做成功。这其实是个很现实的问题，因为很多时候项目失败了，个人的利益并不会受到什么明显的损失（暂时的），所以很多人都没有太当回事。
团队能力：这里指的是当前团队的整体研发效能如何。需求人员能否快速明确用户的真实需求并反馈给团队，研发人员是否有能力快速、高效的完成编码，是否有足够成熟的流水线来保证发布和持续测试。这个团队成员每个人心里都有杆秤，冷暖自知。
个人能力：作为测试的你，是否有足够的能力在短时间内构建部分自动化的验证手段来反馈当前版本质量，是否有足够的激情相信这个项目能做好，并为之付出200%的努力？能够愿意改变现状，提升自己并试着影响团队成员。
想清楚之后，其实就很简单啦，下面给出三个可能的团队表现。涉及到的工具和流程仅限于个人的认知，如果有更好的方案，可以提出来一起交流学习。
团队A：
针对现状，项目负责人能够稳定客户并给出阶段性的需求，研发人员优先熟悉代码并快速理清调用关系，在尽可能不变更原有接口的情况下实现重构和需求实现，并在流水线上部署、验证。测试人员优先针对当前版本梳理核心功能并实现接口级的自动化脚本，以确保核心的老功能不受影响，或者能够第一时间发现此类问题，做为最高优先级解决。确保沟通流畅，最好当面沟通，节约时间。全员努力，熬过最初的两三个迭代后，一切都会好起来的。
说明：
1. 稳定客户做为第一优先级，没有客户就没有后续的项目了。
2. 开发在实现时，尽可能不要改动原来接口的输入和输出，因为你也不知道影响面会多大，涉及的业务要么用新接口，要么接口内部逻辑重构。在这个阶段需要容忍一定的垃圾代码。
3. 要有完善的持续集成流水线，能够快速发版，集成验证，现在有很多成熟的工具可以使用。
4. 必须梳理核心业务的接口场景自动化测试脚本，做到快速回归，在没有多余时间做全量回归的情况下，需要保障核心功能的稳定，不论是测试环境还是生产环境，都需要监控。
5. 沟通流畅，在这种场景下，肯定不会有写文档的时间，需求澄清、架构设计、测试设计等，快速沟通解决问题。
6. 坚持3~4个迭代，熬过最黑暗的时刻，一切都会好起来的。
团队B：
针对现状，项目负责人能够稳定客户并给出阶段性的需求并同步给团队。在迭代会上明确版本的研发任务及时间要求。开发人员在接到任务后，根据明确的需求进行迭代开发，并在开发过程中熟悉原有项目逻辑，做好自测。测试人员根据研发任务编写测试用例，并积极完成验证，及时反馈缺陷。并在上线前明确当前版本质量，给出风险评估。线上问题及进跟进（确保发现问题—验证问题—回归问题-反馈给客户 这条线路的闭环。有多少人能做到？）。
说明：
1. 稳定客户做为第一优先级，没有客户就没有后续的项目了。
2. 每个环节做好自己份内的事，需求方明确需求，开发完成需求并自测，测试人员验证问题并跟踪质量，评估风险
3. 做好质量反馈的闭环，测试做为产品质量的推动者，跟踪并反馈项目质量问题。
4. 大家加班加点，事情总归会朝好的方向发展
团队 C：
针对现状，大家还是按正常的项目流程来，该做什么做什么，不接受上游没完成好的产物（需求不明确、开发过程不严谨，没有文档和交付时间），在保留好证据的情况下做好甩锅的准备，项目失败后确保不会危及到自己就好。
说明：
1. 好像也没什么好说的，自保为主。
这三个团队其实没有严格意义上的哪个好哪个不好。因为很多时候并不是个人决定的。做为个人，要清晰的知道自己所处的团队是怎么样的。你不能指望处在C团队的测试人员做A团队的测试人员做的事，那样只会让自己心累。个人的建议是：努力提升自己，让自己早日进入A团队，而不是先想着进入A团队，再提升自己。（很多人都有这个误区，觉得只有先到了好的环境，自己就能成长，别骗自己了。一定是优秀的团队去寻找优秀的人）
