如何不让“测试”成为敏捷的绊脚石？
最近一次，也就在上个月做的一次在线调查显示，大约60%的公司/团队已开始进行敏捷测试，而之前的调查显示则只有51.2%，不管数据是否存在一些误差，但历史的车轮总是滚滚向前，敏捷开发模式会不断扩展，渗透到研发的每一个角落，甚至向运维渗透，由此产生DevOps。
但是，从我写 第一篇“敏捷测试”文章（2010年发表在CSDN《程序员》杂志上的“敏捷测试的方法和实践”），过去八年了，感觉国内软件敏捷测试进步不大，许多问题依旧存在，不少人的困惑也没有消失，甚至不断增长。从敏捷模式落地看，开发遇到的挑战的确比测试要小。虽然敏捷提倡TDD，但开发却很少去实施TDD，甚至单元测试也没多大改善，根据 国内软件测试现状调查分析报告 调查结果显示 要求做到80%以上覆盖率的企业不到20%，多数企业根本没有要求。单元测试本来是敏捷测试的基础，而由于任务重、开发强势，单元测试而被忽视。持续集成，更多依赖于特定的配置管理团队和Jinkins这样的工具实现，开发只是在check in时间上有一个配合。许多持续集成，也只是实现了持续构建，而缺乏良好的自动验证。所以，在敏捷开发中，开发不容易成为瓶颈，而测试则容易成为瓶颈，这主要有以下几个原因：
开发的单元测试做得不好、做得很少
回归测试的工作量不断增大，而迭代周期是不变的
“测试:开发”的配比很低，测试工作其实不低，但人太少。（可以参照谷歌，那么开发人员就要做足够的测试，但又不是；也可以融合，但又不敢融合）
测试自动化没那么容易实现，不仅因为测试人员少、能力弱，而且产品耦合性强、可测试性低
不恰当的测试策略、测试方式或测试方法等
无论是去年的调查还是今年的调查，主要的问题依旧表现在这些方面：
排在第一的是“需求I问题”。在各种场合，人们也都抱怨“需求不稳定、需求变化过于频繁”。这里肯定有大部分研发人员对敏捷宣言中“拥抱变化胜于遵循计划”的误解。敏捷宣言中“拥抱变化”绝不是拥抱人为造成的需求变化，如因为在需求分析上投入不够、评审不到位、需求表示方法问题等造成的需求变更。拥抱这样的变化，对企业的影响只能是负面的，只能增加研发返工的概率，最终增加企业成本。我相信敏捷宣言中“拥抱变化”，是拥抱“用户或业务真实需求的变化”。我们能够及时交付用户所需的新特性，是为了适应用户或业务真实需求的变化，而不是为了纠错研发人员自己的疏忽、粗心大意或不认真。
在许多人眼中，敏捷只是代表快，快速迭代，往往忽视敏捷最核心的理念是“尽早向客户交付价值”。交付价值，没有价值的东西不交付。敏捷不代表交付功能特性越快越好，而是交付有价值的功能特性越快越好。
没有良好的单元测试、没有良好的设计甚至没有良好的需求，这些问题的暴露可能就落在测试上、产品线上，更何况我们还有“代码重构”、“灰度发布”、产品线上troubleshooting等大招，哈哈。有些开发甚至喜欢troubleshooting，没有troubleshooting，怎能体现他们“强大的实力”？出现问题，会打“测试”几大板，又体现开发的威武，何乐而不为？
如果原来不重视需求、设计和代码的质量，实施敏捷以后，可能会更加肆无忌惮地忽视需求的分析和评审、设计和代码的评审、单元测试等等，那么情况只能更糟糕。研发这过程会流失了很多，包括客户和金钱。
实际上，没有人去计算因需求、设计、代码的问题而返工造成的成本——劣质成本（COPQ）。只要大家足够忙，不断有新的特性交付（哪怕是错误的特性），似乎一切都OK。
测试人员能力弱是另一个大问题，毕竟在国内或多或少存在这样一种错误理念——干不了开发就干测试。有不少人，把门槛相对低的测试作为进入高薪IT行业的一个入口。许多人干测试，并不是热爱测试，而只是找到一个相对体面的工作。正如在 国内软件测试现状调查分析报告 点评道：人的问题可能是最根本的问题，敏捷文化、价值观也是由人来承载，自动化测试也是由人来实施，方法、流程等改进也都是由人来驱动。人的素质和能力达不到，搞敏捷就会搞得很辛苦，加班比以前更多了，可能质量和效率并没有提高。
国人喜欢关注具体的技术和工具，而不关注“文化”或思维方式，这对进行敏捷开发也是很危险的。现在大多数开展敏捷开发，都是采用Scrum模型，而Scrum的确没有教你如何做软件开发，因为Scrum模式台简单、通用了，几乎可以应用到任何一个行业或领域，而不像XP，其中12项实践中大部分实践只适合软件开发。BDD看似简单，但也解决了软件工程中最难的“需求问题”。
人们的思维方式也会在变，今天朋友圈就被“陆奇为什么值钱？因为他的原则值钱”这篇文章刷屏。人们也更关注做事的原则。做软件测试，大家或多或少也会坚持一些原则，有的测试人员是潜意识的，多数测试人员是有意识的，更优秀的测试人员是会主动运用测试原则制定测试策略。测试的原则代表着测试思维。
回到敏捷开发中，测试如何突破瓶颈？
之前给华为做的讲座是谈到这是个方面：
今天会多谈一些，但有些更深的内容（一时半会说不清的）则忽略。
无论采用瀑布模型、敏捷模式，“测试计划、测试分析与设计”没有明显的差异，这些能力都是测试的核心能力，都是必须建设的，虽然在敏捷开发中，尽量简化测试计划——一页纸测试计划。但本质上没有改变，写测试计划就是根据上下文来确定，不是为了计划书而写，而是真正能指导测试的设计与执行，就可以。但有些能力是不一样的，例如自动化测试能力，虽然在瀑布模型也很重要，只是传统开发周期长、需求稳定、清晰，测试配比相对也比较高，没有自动化测试也能支撑测试的正常运行，但在敏捷测试中，没有自动化测试就可能是寸步难行，久而久之，一定敏捷不起来。
概括起来，让测试敏捷化，需要从下面七大方面做一些转变、改进，甚至是彻底的文化革新或技术突破。
测试思维
过去，测试更关注发现Bug，更突出测试对质量负责。要使测试能敏捷起来，必须强调质量是构建起来的、团队对质量负责，加强需求/设计评审、加强单元测试。
2. 测试周期
尽最大努力缩短软件测试周期，适应持续交付，确保测试不成为交付的瓶颈，如：
需求即测试（如BDD、需求实例化等），减少中间转换环节，与开发、产品/业务一开始就达成共识；
已知测试，不写测试用例，直接写测试脚本；未知部分，先探索式测试，等到如何测试，就直接转化为自动化测试。参考：软件测试的一个新公式引起的思考
每个测试（test是，相当于一个test case）的时间低于60秒，这就需要进行分层测试，加强API测试。
测试脚本相对独立，可以拆分，并行执行测试，以缩短测试周期
3. 自动化测试
从单个工具（如Selenium、Appium）执行测试开始，从一般的脚本扩展到数据驱动、业务封装或关键字驱动脚本等，最终构建完整的自动化测试框架，覆盖全生命周期的测试和各个层次的测试，并体现高度的自动化，从需求可执行、测试建模、测试数据生成、测试设计到测试执行、报告自动生成。
4. 测试环境
传统的测试环境强调独立性、稳定性。
敏捷中也要有独立的测试环境，也需要确保测试环境的稳定性，但更强调采用Docker新技术和虚拟机技术，实现更快速的自动部署，并和整个开发、质量管理、运维等系统的集成，形成从开发到运维端到端（扩展为DevOps）的测试环境。在这样的环境中，不仅能够完成测试的计划、设计和执行，而且可以实时监控系统运行行为和日志分析，实现深度的用户行为分析、及时收集用户反馈，及时改进测试的设计，并帮助开发预防缺陷。
5. 度量
越快越要透明，越需要度量，否则就会混乱，欲速则不达。况且，软件及其开发，就是数字化工作，度量是相对容易的。虽然全面的度量指标体系不能一步到位，但可以逐步丰富、改进或优化。一直反对像CMMI、TMMI将度量、量化管理放在Level 4，缺陷预防放在Level 5，而且隔离过程域（参考：解密TMMi、CMMI）。每个公司只要存在就有了过程定义，虽然不完善，过程需要改进，其它关键领域（测试计划、非功能性测试、相互评审）都应该先动起来，度量对测试一定是一个很好的支持，数据驱动质量管理对软件研发就是天生的，很早就可以动起来，可以帮助测试过程改进。
从缺陷度量、测试用例执行来基本的测试度量，可以扩展到全面的质量度量，构建完整的quality dashboard，而且现在也有类似SonarQube这样的工具或平台支持。
6. 测试与开发融合
质量中心作为管理部门，需要覆盖研发、运维、市场销售等各个部门。其成为一个独立部门是顺势而为。但测试是属于研发的一部分，没必要独立，需要和开发融合。之前，测试人常常将微软公司作为标杆，说明测试如何得到重视、测试和开发的比例如何之高，今天这个标杆已经不存在了，因为四年前（2014年），微软就逐渐去掉专职测试人员岗位，都统一成为“软件工程师（software engineer）”。今天看来，微软转型也是成功的。
在敏捷开发转型中，我们也应该消除测试部门，到消除专职的测试人员，从而实现开发与测试的彻底融合。在这过程中，可以设立“Test Owner”角色，负责项目的测试计划（含测试策略制定）、测试工作的质量，指导其他团队成员做好测试的设计与执行，帮助团队建立良好的测试能力。如果在LeSS或SAFe中，可以设立Test Owner of Test Owner。
7. 组织的支撑
测试敏捷化，当然也离不开管理层的大力支持，包括倡导先进的敏捷思想与文化、组织结构的改变、为开发人员提高测试培训等，预算、人员等方面的支持，思想文化层面的支持不需要多大成本、甚至不需要成本，只是领导要有这样强有力的意识。而组织结构的改变是局部的，风险是有限的，企业需要承担一定的风险，不变则一定等死，变才有可能新生。
具体实践，统一资源，在公司层次建立自动化测试框架、测试平台或测试云服务，同时建立测试能效团队，让一部分测试工程师加入进来，为公司提供测试所需的、较通用的测试工具。
参考：