敏捷驱动QA改变
敏捷理念由来已久，若从敏捷软件开发宣言的发布算起，今年已经是20周年了。在这漫长的岁月里，越来越多的团队在“四个高于”的价值观引领下，以十二项原则为指导，欣然求索而持续演进，在实践中探寻更好的软件开发方法。虽然敏捷自身一直在变化，不同团队对敏捷实践的落地也多有差别，但人们对敏捷核心的理解趋于一致。“追求更短的反馈环” -- 便是其中被大家广泛认可的一项核心目标。假如以终为始来看，那么：
Inception的采用，拉近了项目团队与产品团队/用户的距离，在获得需求有效澄清的同时也对软件设计进行快速反馈和更新。
Pipeline的采用，加快了软件集成的效率和频率，挂载流水线上的分层自动化测试缩短了代码检测的反馈环，这也是落地快速交付的根本之一。
而快速交付的实现，完成了产品/用户-项目团队-外部市场的闭环，小步快走，缩短了市场验证的反馈环。
然而，以“追求更短的反馈环”为目标的敏捷，不仅仅在以上方面改变着敏捷团队的开发流程和技术实施的软件工具，也真切改变着团队人员的角色认知，工作内容和思维方式。在这篇文章里，我们来梳理一下在敏捷驱动下，QA这一角色如何从传统Tester一路走来并不断演化（或许不久的将来会更名为QE）。
曾几何时，CMMI还流行，研发中心的人员按职能维度被划分为PM团队，开发团队，BA团队和测试团队等（这可能是角色墙或部门墙形成的一个条件），那时测试团队中质量管控的角色则被称为：
手工测试工程师
自动化测试工程师
专项测试工程师（诸如：安全测试，性能测试，无障碍测试）
测试经理
在项目敏捷化转型的过程中，上面各个团队的经理，当然也包括测试经理，或情愿或不情愿地从自己团队中抽出一部分人力资源组建出特性团队。这个团队在敏捷深化的过程中也经历类似塔克曼团队发展模型的历程，下面我们从质量的角度来进行分析。
组建期
这个时期，手工测试，自动化测试人员可能是分开的，甚至专项测试人员只是兼职参与。团队成员按照原来瀑布开发模型固有的阶段式方式，像4x100米接力赛一样合作，任务在角色之间一棒接一棒，虽然团队交付周期缩短成2到3周，但敏捷却被玩成了小瀑布，不同角色各扫门前雪，整体velocity并不高。你会发现，手工测试和自动化测试由于目标不同（一个为了发现缺陷的总数，另一个为了自动化测试覆盖率），在配合上也貌合神离达不到1+1>2的效果。在这样的情况下，将质量把控统一到一个角色上刻不容缓，便有了Quality Assurance的角色。
震荡期
到了这个时期，随着CI/CD pipeline等基础设施的优化，和团队成员的磨合，整个团队的研发效率震荡提升。敏捷团队有了QA这个角色来负责项目质量，测试工作范围较以前大大增加。角色统一后的QA，可能会出现力不从心，总担心Ready for QA的卡测不过来，双拳难敌四手（何况有的团队开发测试比在8比1以上）。测试过程中如何更精准得实施测试，如何从已有缺陷的规律中让开发人员吸取经验提升Build稳定性，怎样才能前摄性得预防问题的发生？对这些问题的思索，逐渐让QA演变为Quality Analysis的角色。
规范期
敏捷追求持续改进，如何更好实现敏捷铁三角中对质量的追求？如何更进一步缩短项目反馈周期？我觉得形成规范的过程，不仅是研发流程的规范，软件工具的规范，交流沟通的规范，也是一个化繁为简的过程。人常说，积少成多，众志成城。在项目质量上更多凭借团队的力量对每一件过程结果进行快速反馈，便是不二法门，也是更成熟的QA -- Quality Advocate手中高举的旗帜。
也许有人觉得，说来说去不管哪种QA，都只是对这个英文缩写的演绎。如果愿意，QA也可以被理解成Question & Answer。我是认可Question & Answer这种诙谐的说法的，试试回忆一下在项目中是提出问题和追寻答案较多的那个人，不正是QA吗？
不过，为了大家更好理解，我们在这里把对QA的三种解释称作三顶帽子，下面来从工作内容进行划分：
Quality Assurance
质量保障，是对传统Tester工作的扩展，是对传统四个测试角色的统一。它将角色的思考范围从具体测试执行的“点”提升到测试设计+执行的“面”。
Quality Analysis
质量分析，在质量保障的基础上加入了思辨的成分，如何从业务价值的交付出发更有效地改善质量，将工作方向从质量检测推进到质量提升。这样一来，QA的角色逐渐走出了独立的角色范畴而上升到团队影响的层面。
Quality Advocate
到了质量倡导，QA对团队的影响更加突出，更像是质量的布道者，让所有角色对质量的思考遍布所有活动和阶段，把团队在质量管理的持续改善量化展示，致力于将质量内建转化为团队的基因，并在合适的时候孵化出新的质量实践。
从上面的描述，大家或许会觉得QA的三顶帽子有某种渐进关系，其实不然。既然是不同的三顶帽子（就像鸭舌帽，礼帽，头盔），敏捷中QA就会在不同的场合挑选适合的帽子戴上。只有以自动化测试作为效率基石，质量保障拓宽覆盖范围，质量分析精准优化，质量倡导沉淀文化，协同一致才能造就成熟的敏捷QA。
在敏捷项目中，是什么推动者QA工作内容的变化？我觉得这个推动力，一方面源于敏捷实践带来研发效率提升后对下游角色的倒逼，另一方面也出自质量人员对敏捷理念的遵循和演进。而这些在改变工作内容的同时，也促成了思维方式的改变，比如下来将要讲到的一个目标，一个依据，三大法宝。
以预防缺陷为目标
缺陷修复的成本会随着发现缺陷的时间越晚而越昂贵，更早得发现缺陷可以有效降低软件研发成本。虽然发现缺陷数目被换算成测试人员绩效组成，这种现象直到现在还能在某些组织见到。这样对缺陷修复成本趋势的不屑，更多是人浮于事的结果。测试的目标是预防缺陷而不是发现缺陷，在敏捷组织被广泛推崇。
以测试宣言为依据
敏捷宣言是敏捷组织的圣经，由敏捷宣言演化而来的敏捷测试宣言，强调持续测试，精准分层自动化，认同团队共担质量，推崇质量内建。为QA的实践探索提供了理论的依据。
法宝一：沟通中心化
在探索QA实践的过程中，为了落地测试宣言中的理论，对QA这个角色在决策沟通和流程影响方面提出了很大挑战。QA从拿枪杆子的技术岗位，要变成文可安邦武能定国的大才，也要有上厅堂下厨房的自如。
法宝二：质量内建
质量内建作为预防缺陷最重要的措施，QA参与到敏捷过程中的各项活动。在每个有过程结果产出的活动中，QA来提出问题，激发其他成员对于质量和影响的思考，使团队时刻把质量挂心间。
法宝三：分层自动化
为缩短代码修改验证的反馈环，自动化测试作为Pipeline配置的硬性条件，重要性被提得更高。自动化脚本设计得到分层设计，在系统架构中由低到高分为单元测试自动化，组件/服务测试自动化和系统测试自动化。这样一来，自动化的测试角度更多样，覆盖更精准。
敏捷的演进推动者角色的演变，角色的演变又反过来推动敏捷的演进。很多事情都是这样的道理，因果流转，互为促进。
讲了这么多，总会有留心者发现，上面所说的敏捷QA的影响范围始终没有跨越出团队级别。我们知道随着企业数字化转型的深入，敏捷已经由最初的团队敏捷，扩展到业务敏捷，又在加持EDGE后进化出组织级敏捷。那么，QA这个角色在敏捷演化中有没有发展出一条对应的职业路线？
答案当然是肯定的，现在是时候祭出21年TW最新的QA职业路径的原型图了。下面，我们一起学习Global对QA职业路径中每个节点/职位产出(Outcome)的定义。
Quality Practitioner
质量执行人，在敏捷团队中实现：
强壮，可扩展的自动化套件以支持持续交付
将高质量的软件交付到生产环境以满足业务目标
通过持续测试实现快速反馈
Quality Anchor
质量专家，在敏捷团队或客户线(Account)上，从质量治理角度与业务，设计人员，架构师等各类角色沟通，独立推动：
促成业务和开发团队在质量策略、风险及应对措施、团队培养、强壮而可扩展的自动化套件方面保持一致，从而实现持续交付
将高质量的软件交付到生产环境以满足业务目标
通过持续测试实现快速反馈
从上述的分类产出可以看出，Tester和Quality Assurance可以被mapping成Quality Practitioner，而Quality Analysis和Quality Advocate则mapping成Quality Anchor。
随着质量专家对客户在质量影响力的提升，更上一层楼，QA的发展会进入更广阔的平台。这也是最值得在国内探索的。
Quality Enabler
质量教练，在更大的复杂交付项目或数字化组织转型过程中做到：
跨职能/地域/团队定制化推行质量原则和优秀实践
采用最优的敏捷QA实践
获得内嵌于团队的质量基础，原则和理念
Program Quality Leader
项目质量经理，在具有多个团队的大型复杂交付项目中实现：
跨组织监督和协调多个项目，产品和其他战略计划
在跨职能团队间实现高效沟通
平稳、快速地大规模持续交付
领导出密切合作的QA团队
Quality Strategist
质量策划师，深入研究复杂项目或敏捷转型组织并提出对症的质量策略和落地规划。
制定跨团队和项目的质量方案和测试策略
规划明确的目标、行动计划和资源调配以促成执行落地
为客户创造独特的商业价值的新机会
Quality Partner
质量合伙人，作为客户高层管理团队(CxO level)值得信赖的合作伙伴，推动在客户组织级建立并推行QA纪律：
顺应组织愿景，持续的质量交付中在组织级完成流程实践和策略转型
在客户组织中实现质量文化和质量理念的建立和内化