敏捷开发中QA如何做质量管理？

测试积点老人

经常有人会问我，敏捷模式下，QA的职责是什么？QA有什么价值？我们还需要QA吗？敏捷转型中遇到的问题，QA能帮助解决吗？这些问题以前也思考过，笔者就是QA出身的，曾经在中兴通讯做过两年多的PQA，在中兴通讯的敏捷转型中也遇到过这些问题。

先总结一下敏捷转型中遇到的问题吧,QA的工作也是要围绕这些问题展开的：

很多公司希望采用敏捷，但是又没有把握

传统的瀑布式开发流程在公司已根深蒂固，虽无法满足快速发展的需要，但大规模改动又不现实，老板也不愿意花太多的成本

缺少敏捷软件开发专家和人才

研发人员需要观念的转变和方法培训

缺乏相应的质量控制方法

需要经常的和及时的质量度量

自动化测试不能落到实处，持续集成发挥不出作用

人员水平参差不齐，有人支持有人反对

笔者也先后参加过多次华为、腾讯、平安科技等公司的敏捷推行者的分享活动，也参加过Thoughtwork、康仕诚、ScrumCN等专业机构的培训，对国内敏捷项目的质量管理有一些想法，结合笔者这几年的质量管理经验，总结一下：

• 1）QA角色的转变
  

QA以往主要还是作为警察的角色，从事各种审核活动，要从警察转变成教练。传统项目里，QA习惯拿着事先准备好的检查单，对项目一条条做审核，发现问题开不符合报告，给团队的感觉就是一个监工。虽然笔者自己也不喜欢人家这么说我，但确实我们给项目成员你的印象就是监督。

中兴通讯从2014年开始，各研究院都大力推行敏捷转型，刚开始觉得有点失落，都敏捷了，都不知道该怎么下手了，审核不能叫审核，要叫观察，审核报告也要叫观察记录。经过几个月基本上适应了，QA、项目管理员都往敏捷教练的方向上转，在外界专业教练的指导下，引导项目开展各类敏捷活动。

比如该如何开站立会议，该怎么去做迭代的计划等等指导性的工作，不过以前的项目团队划分成十多个特性团队，一个人要跟十几个PO、SM打交道，对于QA的沟通能力增加很多，每天奔赴各个团队。

2）QA参与各项活动，如需求梳理会、计划会、早会、持续集成看板、演示、回顾会等，各项持续集成结果也都推送到QA，这样便于及时获取团队的信息，也便于QA输出各类观察记录、报告。

3）自动化回归测试。敏捷团队没有自动化会成功吗？可能也会成功，但我们所知道的成功团队都依赖于自动化回归测试，如腾讯和支付宝公司的Selenium框架，阿里巴巴和淘宝网的QTP框架。笔者咨询认为，敏捷开发利用测试来指导开发，为了编写的代码使测试通过，需要快速而简单地运行测试，没有短期反馈周期和安全的回归测试，团队将很快陷入技术债务，缺陷不断增加，速度越来越慢。

4）提供并获取反馈

反馈是敏捷的核心价值，敏捷的短期迭代可以提供持续的反馈以帮助团队正常运转，测试人员则通过自动化测试结果、探索性测试的发现和系统实际用户的观察结果的形式帮助提供支馈。如你怎么知道客户手里拿到了预期行为的正确示例？你怎么知道编写的测试用例正确地反映了这些示例？开发人员通过查看测试用例能够理解应该编写什么代码吗？QA和测试人员应该询问开发人员是否得到了足够的信息以理解需求并是否能够指导编码，询问客户是否理解质量标准，应花时间参与迭代计划会议和回顾会议以讨论这些问题并提出改进方案。

5）构造核心的敏捷实践活动

软件行业有一句老话是：软件质量是设计出来的。对于敏捷开发也是如此，笔者认为没有一些基础的实践活动，无法产生出高质量的软件。

持续集成：持续集成（CI）是一项软件开发实践，其中团队的成员经常集成他们的工作，通常每人每天至少集成一次，每次集成通过自动化构建完成。利用持续集成可以让缺陷在引入的当天就被发现并解决，降低缺陷修改成本；将集成工作分散在平时，通过每天生成可部署的软件；避免产品最终集成时爆发大量问题。QA可以关注这些持续集成发现的问题分布情况、解决情况、构建周期，及时度量出相关数据。

看板：最便宜的敏捷工具，可实现价值流、可视化、拉动、限制在制品、找出瓶颈等多个作用。用户故事可以用看板，QA自己的任务同样可以用看板管起来，便于QA之间互相沟通、对齐信息。

自动化测试：持续集成的前提是有自动化测试用例，以及代码静态检查、代码行覆盖率、代码复杂度等各种工具，如果这些没做起来，只是持续构建，并没有太大意义。自动化测试属于防御性测试，把所有的质量风险用穷举法列出测试用例，然后测试用例提前写好，然后写代码帮你执行，预防缺陷的泄露。但是成本同样非常大，是否能推行起来，就看领导的魄力了。

每日晨会：每个团队每天大概花15-30分钟，回顾昨天做了什么、昨天有些什么问题、同时也会介绍每个人今天计划做些什么工作（特点：是站着开会）。一般主持人由敏捷团队的成员轮流担任，这个时候可以了解每天发生的问题。QA可以参加晨会，根据自己的观察提出问题。

结对编程：两位程序员在一台电脑前工作，一个负责敲入代码，而另外一个实时检视每一行敲入的代码；操作键盘和鼠标的程序员被称为“驾驶员”，负责实时评审和协助的程序员被称为“领航员”；领航员检视的同时还必须负责考虑下一步的工作方向，比如可能出现的问题以及改进等。有助于提升代码设计质量；研究表明结对生产率比两个单人总和低15%，但缺陷数少15%，考虑修改缺陷工作量和时间都比初始编程大几倍，所以结对编程总体效率更高，同时结对编程能够大幅促进团队能力提升和知识传播。不过这个实践也是最难推行的，往往只有进度不紧的时候才会尝试。

用户故事：用户故事是站在用户角度描述需求的一种方式；每个用户故事须有对应的验收测试用例；用户故事是分层分级的，在使用过程中逐步分解细化；典型的描述句式为：作为一个XXX客户角色，我需要XXX功能，带来XXX好处。用户故事的好处是：用户故事站在用户视角便于和客户交流，准确描述客户需求；用户故事可独立交付单元、规模小，适于迭代开发，以获得用户快速反馈；用户故事强调编写验收测试用例作为验收标准，能促使需求分析人员准确把握需求，牵引开发人员避免过度设计。QA可以引导项目团队如何编写用户故事、验收标准。

迭代回顾会议：在每轮迭代结束后举行的会议，目的是分享好的经验和发现改进点，促进团队不断进步。会议需要Team全员参加，气氛宽松自由，畅所欲言，头脑风暴发现问题，共同分析根因；会议关注重点是Team共同讨论优先级，将精力放在最需要的地方（关注几个改进就够了）；会议结论要跟踪闭环。QA同样可以参加回顾会议，引导团队如何召开，并跟踪改进事项。

总之，笔者认为，质量是整个敏捷团队的职责，团队中的每一个人都应该关注手边的一个任务或者故事，敏捷模式下的质量管理更具有挑战性，但与传统瀑布模式相比，其在应对需求变化、提升产品质量、加快需求响应、缩短交付周期、提前暴露风险、及时激励员工以及平滑人力资源的使用等方面具有明显优势。敏捷的焦点在于交付有价值的软件，一直到客户满意为止。在这个“快鱼吃慢鱼”时代，要想交付好而快的产品，不防用敏捷模式试试。