清朝陈澹然在《寤言二·迁都建藩议》中说：“不谋万世者，不足谋一时；不谋全局者，不足谋一域。”对于我们测试来说，要做好测试，达成测试目标，也需要谋划谋划。首先需要了解我们的测试需求是什么？我们需要测试什么样的系统？这个系统对缺陷的容忍度是怎样的？测试过程需要使用什么样的技术？一个信息管理系统和一个银行账务系统对缺陷的敏感度是不一样的。我们有多少资源可以用于达成目标？例如我们有多少测试人员，有多少设备（手机、POS 机、金卡键盘、苹果电脑等等），有多少测试环境可用？我们有多少有效时间可以用于测试？我们测试需要有多少轮次？如何回归测试已发现缺陷？
我们先假设目前面对的是一个新项目或者说是一个新产品，为了增加带入感，也方便解说整个敏捷项目的敏捷测试工作如何进行，我们先从一个故事开始。我们用这个故事贯穿整个课程，让童鞋们跟着这一故事主线完完整整的体验一个完成的敏捷项目是如何完成测试工作从而成功交付的。
我们的主人公小明童鞋是一家电子商务公司的测试经理，主要工作是带领测试小组完成公司电子商务软件的测试工作。2月22日刚过完春节上班的第一天，老板把销售、市场、需求、研发等部门的负责人和骨干童鞋都叫到了公司大会议室开会。老板说：“童鞋们，市场竞争越来越激烈，飞机票代订业务也越来越难做。董事会要求我们今年的营业额要比去年增加20%，成本要降低10%。今天召集大家开会的目的就是请市场部、销售部和研发的童鞋一起献计献策，群策群力完成今年的业务目标……（此处省略老板为鼓舞大家达成目标出口成章，意气风发的演讲1万字）”
销售部和市场部的童鞋分别提出了电子商务网站增加在线推广和售票的业务需求。为了达成以上目标经老板同意专门成立了“华山论剑项目组”。项目组包括2个 Scrum 团队，和1个系统验收团队。小明童鞋所在的 Scrum 团队为“战狼”队，负责服务端开发，其组织架构为产品负责人1名、敏捷教练1名、研发童鞋4名、测试童鞋2名。这是一个典型的 Scrum 敏捷团队。小明同学有幸参加了这个团队，并负责主导团队测试工作，如图1为敏捷研发团队成员组成。
图1 敏捷研发团队
项目需求（产品需求）确定后，测试的同学该做哪些事情呢？测试管理中贯穿整个测试过程的是人员、技术和过程管理。在测试准备时首选是对测试需求的了解，根据测试需求确定测试范围，规划测试过程，确定所需要的资源和培训需求。在我们这个故事中，小明童鞋是测试负责人，在测试准备阶段，项目开始前他应该做哪些事情呢？举例如下：
人员需求培训和学习。作为敏捷团队的一员，测试人员应该熟悉自己所测试的产品需求。如果不了解需求很难完成测试目标。
技术准备。敏捷项目应该尽可能使用工具和自动化测试提高测试效率。最基本的测试应该考虑接口自动化测试技术。因此小明童鞋应该评估是否需要相关的技术培训或安排自学。
环境与设备准备。准备测试所需的服务器（虚拟机、云服务），准备搭建测试所需的应用环境。如果需要其它设备，例如移动 App，测试童鞋应该考虑用于测试的不同型号手机是否具备。如果环境和设备不具备应该考虑申请相关设备和资源，或者提出采购等等。有时采购过程需要一些时间，因此为了不影响测试进度，应该提前申请采购。
测试过程规划。敏捷项目一般采用冲刺的方式完成开发任务。测试过程应该与冲刺规划保持一致。单元测试、接口测试等相关活动应适应整个敏捷项目的节奏，并给每个测试任务分配合适的工作时间。
我们应该根据软件开发的整个规划过程来规划测试过程。在小明童鞋的故事中，软件开发使用的是 Scrum 敏捷开发。我们先谈论团队级别的 Scrum 敏捷开发。如果需要再谈论企业级的 SAFe 敏捷开发。由于 SAFe 敏捷开发涉及到系统验收团队、架构团队等等需要专门的课程讲解。咱们这里先从团队级别开始介绍。由于小明童鞋是团队级别的测试负责人，由这个开始也比较合适。如图2为 Scrum 流程图。
图2 Scrum 流程图
产品列表梳理（Product Backlog）：产品负责人与敏捷团队一起梳理产品列表。作为测试团队成员应该从测试的角度考虑梳理出的产品列表是否可测试。应该如何描述才能方便测试验收。
冲刺规划(Sprint Planing)：产品负责人与敏捷团队一起安排冲刺的时间跨度和本轮的冲刺内容。测试人员根据项目（产品）冲刺规划安排自己的测试节奏和内容。
冲刺列表（Sprint Backlog)：产品负责人与敏捷团队一起确定本轮测试需要完成的用户故事，确定 DOD（Defined OF Done）条件。测试人员根据用户故事编写测试用例和自动化测试代码。在 BDD 中，这时就可以开始编写自动化测试代码了。
每日例会（Daily Scrum）：一般早上开始工作时进行每日例会。回顾昨天完成工作，规划当天工作内容和向小组通报遇到的问题。对于测试人员来说测试工作节奏应该和用户故事的粒度和开发工作的节奏相适应。例如开发人员4个小时完成开发工作，测试人员一般应在1-4个小时内完成测试工作，以便当天用户故事达到 DOD 状态方便交付。
冲刺评审（Sprint Review）：产品负责人与敏捷团队一起评审本轮冲刺的产品增量（Product Increment）是否满足用户故事的 DOD 条件，是否可以发布。测试人员一般在冲刺评审过程中作为演示人员向产品负责人和敏捷团队演示可发布的软件产品。
冲刺回顾（Sprint Retrospective）：敏捷团队回顾本轮冲刺的过程，总结经验教训。测试人员可以在这个阶段看看测试工作存在哪些问题，有哪些方面可以提高等等。
在测试管理方面，测试过程、人员、技术设备等确定后，接下来我们就可以根据梳理出的产品列表开始测试需求分析了。
GitBook:十招玩转敏捷测试
微信公众号：
如果觉得《十招玩转敏捷测试（2）敏捷测试中的人 技术与过程管理》对你有帮助，请点赞、收藏，并留下你的观点哦！
