1. 敏捷团队下的QA

1.1 敏捷QA的职责

    敏捷QA的主要职责是主导并促使与质量相关的活动在团队内发生，包括但不仅限于测试。

    除了要有基本的测试知识外，必须要熟悉一些敏捷相关的基本概念以及实践，比如用户故事、迭代、迭代计划、回顾会议等等。敏捷QA几乎会参与整个用户故事的生命周期，从分析，启动，开发，验收，测试到最后的展示，尤其在启动，验收和测试这三个环节发挥着非常重要的作用。

    另外，敏捷QA会同时工作在多个迭代当中，在进行当前迭代用户故事的测试验收等活动的同时，也经常需要做前一个迭代的收尾工作以及下一个迭代的准备计划等。

1.2 传统QA vs 敏捷QA

    传统的QA大多作为一个单独的测试团队，由于瀑布模型，QA通常在开发流程后期进行独立进行测试，被当做软件质量最后也是唯一的保证。在业务上缺乏与业务人员的直接沟通，对业务的理解不够清晰可能导致一些潜在的缺陷无法被找到。最后在项目发布阶段，没有机会参与发布计划的制定。

    敏捷团队中的QA更像是多角色开发团队中的一员，质量保证与测试贯穿于整个开发流程中。可以与BA, Dev等其他角色一起pair完成工作。关注点不仅限于测试，更多关注并强调风险；为了对业务有更深的认识，需要和业务人员直接沟通。同时项目发布时需要参与制定发布计划。

    敏捷QA是提出建议者而非看门人，需要在参与的每个阶段提出自己的建议，而不是等到开发流程最后来对系统进行验证;不仅要验证开发设计是否满足需求，还要发现需求是否能真正体现业务价值，分析是否有不恰当或缺失的需求。比如说，敏捷QA在跟业务人员结对编写验收标准的时候发现业务分析过程中漏掉的需求，在跟开发人员结对过程中跟开发人员讨论某个测试放在哪层实现比较合理等。

    发现风险，并将风险与团队及客户沟通。QA参与整个开发流程，对系统整体的认识和把握可以说是团队里边最全面的，因此也更容易看到系统存在的风险。

    及时向团队提供关于产品质量的反馈，便于调整。在每个迭代结束时候，QA需要分析统计该迭代的缺陷，并结合自己通过测试对系统质量的了解，及时跟团队反馈，讨论分析质量下降的原因以尽快作出改进，或总结质量上升的经验，鼓励团队再接再厉。

    在制定产品和版本的发布计划的时候，QA可以根据自己对产品质量的了解，从测试人员独有的视角提出一些关键的建议。

    QA通过参与开发流程的每个阶段，能够协助团队从内部提升质量，让质量融入到产品开发中来。比如：在故事验收阶段对测试覆盖率的确认。

2. QA的日常活动

2.1 故事生命周期下QA的所需的工作

在单个迭代内部，伴随着故事生命周期，QA的活动有哪些呢？用户故事生命周期包括以下几个阶段：故事分析、故事计划、故事开发、故事验收、故事测试／探索性测试、系统测试和客户演示。QA参与故事的整个生命周期，在每个阶段都会发挥作用。

故事分析阶段：需求澄清，业务场景和验收测试的确认

故事计划阶段：拆分测试任务，在每个故事开发估算基础上考虑测试的时间和估算

故事开发阶段：和开发人员结对实现自动化测试，和团队沟通发现的问题和缺陷

故事验收阶段：开发人员开发完故事后，QA和业务分析人员要在开发机器上进行验收，以提供快速的反馈；同时还要对测试覆盖率（单元测试、组件集成测试、功能测试）进行确认和提出反馈

故事测试／探索性测试阶段：执行自动化验收测试，执行探索性测试，强调会阻碍故事发布的因素，和团队就测试覆盖率进行沟通，为发现的缺陷添加自动化测试

系统测试和客户演示阶段：执行端到端的系统测试，执行业务或集成的用户测试场景，和团队及客户就功能特性的质量和稳定性进行沟通，参与给客户演示功能和特性

2.2 目前的工作流

    目前的工作流程如图，因为要实现单张卡上线，每次测试完单张卡要做一次回归测试。

2.3 每一轮迭代具体的工作

    1. 测试上个迭代遗留下没测完的卡

    2. 进行Story Review，复盘上一轮迭代中遇到的影响质量和交付的问题，找到改进方案，并持续关注

    3. 测试这一轮迭代完成的卡，在此之前完成测试计划，测试环境的准备，测试完成之后编写自动化测试（如果有需要）并进行回归测试，之后上线。

    4. 有测试过程中发现的or其他人反应的bug，对bug进行等级评估，及时fix    

    5. 准备下一轮迭代的story卡，与BA确认需求之后为每张卡编写Test Scenario，尽量覆盖所有情况

    6. 非功能性测试

    7. 质量管理、缺陷管理与反馈

2.4 测试策略

    测试策略是描述软件开发周期的测试方法的概要，测试策略的第一目标是减少缺陷的出现和发布。减少缺陷的出现可以通过测试迁移等方法来解决，在进行软件需求分析和架构设计的时候发现缺陷；减少缺陷的发布可以使用各种测试方法、技术来验证和测试编码完成的功能。所以，测试策略并不是只由测试人员定制的，是由一个团队的各个角色一起来指定和建立的，目的是保证软件的质量，减少缺陷。

    而“测试计划”是用于实施测试策略的。只有充分理解测试策略目的和实施方式，才能充分理解测试策略，为什么要做测试策略，什么样的测试策略才更有意义、更好，怎样实施才能更有效等问题。

    制定测试计划是保证测试策略能被有效执行的一种方式。它告诉了团队在什么阶段，什么样的角色应该执行测试策略中什么样测试技术和测试方法。它主要由测试人员编写，但是应该由整个团队进行评审，因为开发人员、产品经理、业务分析人员甚至用户都可能参与到测试计划的执行中。

    QA主要关注于UI和API测试，UI测试上主要测试用户界面(如菜单、对话框、窗口和其它可规控件)布局、风格是否满足原型设计要求、文字是否正确、页面是否美观、文字、图片组合是否完美、操作是否友好等。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏觅功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

    接口测试主要进行功能测试，包括业务正常流程，覆盖是否全面，参数和边界条件是否符合要求，异常场景（如重复提交，并发提交等）

2.5 常用工具及框架

    Postman：用来手工测试HTTP请求，简单方便

    飞蛾：用来管理测试用例和测试计划

    Selenium：用来编写UI自动化测试

    JMeter：用来实现接口测试自动化及压力测试

3. 如何做好敏捷QA

3.1 勤交流，多沟通

    因为敏捷QA不能被动地等待软件完成交到QA手里再做测试，不能发现缺陷后不管不顾等着开发人员自发地去修复。需要从软件的源头开始介入，在软件的整个生命周期中全程参与。

    敏捷软件开发强调质量内建，在用户故事的生命周期中，作为质量保障的主要负责人，QA需要在每个阶段跟不同的角色反复确认和验证，确保团队对需求理解一致，还要保证跟质量相关的活动发生，比如确保开发人员添加了相关的自动化测试等，所以QA需要和团队的每一个成员以及客户有非常多的交流，而最直接有效的方式就是说话，沉默寡言是行不通的。所以对QA需要和不同角色进行有效的沟通，主动验证质量目标并及时说出自己的想法，在团队内部进行知识分享，协助整个团队参与到测试活动中来，持续提供并获取反馈。

3.2 强大的心理素质

比如在故事验收环节，这个阶段就是业务分析师、开发人员和QA三种角色一起在开发人员的机器上验证用户故事是否被正确地实现。当然任何角色都可以主导这个环节，但效果最好的是由QA来主导，因为可以提前发现缺陷并快速修复。

但是因为这个阶段所有角色都会参与，大家关注点又有所不同，所以心态不好难免就会有各种顾虑，比如，自己会不会太慢了？会不会耽误太多人的时间了？别人会不会很着急？

太多顾虑就会影响你做验收测试，尤其验收阶段的探索性测试。从而使你不能充分发挥QA的作用，而这个环节对于敏捷开发模式下的质量保障来说非常重要，这时候如果具备前面提到的强大的心理素质，就能专注地按照你的想法测试你的场景，当然可以配合一些解释让别的角色了解你的思路，而不是左顾右盼思前想后影响这个阶段的发挥。

3.3 对业务，代码的关注

    相信很多人进入测试这个行业，是因为对测试领域的技术和方法论有浓厚的兴趣，但是对于敏捷QA来说，仅仅对测试感兴趣是不够的。

    敏捷QA需要对整个系统以及业务足够熟悉，这样才能从QA的视角帮助业务分析师和团队发现业务不合理或者缺失的部分（可以在故事审查或者启动阶段帮团队澄清需求）。

    另外如果可以具备一些编码能力，对于做敏捷QA也是非常有帮助的。当然，术业有专攻，并不要求每个QA都会写代码，但是要对代码有一定的兴趣，愿意听开发人员讲解他们的逻辑和实现，并通过提问题了解他们的思路，至少了解他们编写的测试代码。因为在验收阶段，敏捷QA会通过审查开发人员的自动化测试是否合理和全面，来帮助团队建立对自动化的信心。

比如具有丰富的产品知识和对用户业务目标的准确了解，对不同系统和数据库所用到的技术知识的了解，自动化测试的能力和对测试工具的基本了解等等

3.4 管理QA工作的优先级

    敏捷QA最大的挑战是，每时每刻都同时工作在很多事情上，我们可以细数一下敏捷QA的活动：当前迭代的故事审查、故事启动、故事验收、故事测试用例准备、部署、缺陷管理、缺陷分析，前一个迭代的故事收尾，后一个迭代的测试计划、故事审查、故事启动等等。

    另外敏捷QA希望可以做的更多，比如日志分析、性能监控、安全测试等等。

    可以看到，敏捷QA的工作是非常杂乱琐碎的，而且大多活动是和团队中不同成员一起进行的，我听过很多刚刚加入敏捷QA的新人抱怨没有自己思考的时间，忙乱没有目标；也见过很多优秀的测试人员转做敏捷QA后因为不适应这种多线程的工作选择了放弃。确实，在这样一种工作模式下，如果QA不能清晰定义自己工作的优先级，就会被各种杂事牵着鼻子走。

    不擅长管理自己的工作任务、不会划分优先级，做敏捷QA会非常难。

参考文章

http://insights.thoughtworkers.org/agile-qa/

http://insights.thoughtworkers.org/agility-of-qa/

该文章部分来源互联网，如有侵权请联系删除