敏捷开发中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可以参加晨会，根据自己的观察提出问题。
结对编程：两位程序员在一台电脑前工作，一个负责敲入代码，而另外一个实时检视每一行敲入的代码；操作
