测试自动化后，我们还需要QA吗？(2)

　　在这个大前提下，我们再来思考QA在团队里应该做什么以及怎么做。

　　QA的职责

　　Lisa Crispin在《敏捷软件测试》中提到过一个很著名的模型：敏捷测试四象限。这个模型是QA制定测试策略时的一个重要参考：

　　如果按照纵向划分的话，图中的活动，越向上越面向业务;越向下越面向技术。横向划分的话，往左是支撑团队;往右是评价产品。

　　其实简化一下，QA在团队里的工作，可以分为两大类：

　　确保我们在正确的交付产品

　　确保我们交付了正确的产品

　　根据这个四象限的划分，大部分团队可能都会从Q2起步：QA会和BA，甚至UX一起，从需求分析入手，进行需求分析，业务场景梳理，这时候没有具体的可以被测试的软件代码。不过这并不妨碍测试活动，比如一些纸上原型的设计(感谢刘海生供图)：

　　通过这一阶段之后，我们已经有了用户故事，这时候QA需要和开发一起编写用户故事的自动化验收测试。当开发交付一部分功能之后，QA就可以做常规的用户故事测试，几个迭代之后，QA开始进行跨功能需求测试和探索性测试等。根据探索性测试的结果，QA可能会调整测试策略，调整测试优先级，完善测试用例等等。

　　根据项目的不同，团队可以从不同的象限开始测试策略的制定。事实上，Q1-Q4仅仅是一个编号，与时间、阶段并无关系，Lisa Crispin还专门撰文解释过。

　　关于QA如何在软件分析的上游就介入，然后通过BDD的方式与业务分析师一起产出软件的各种规格描述，并通过实例的方式来帮助整个团队对需求的理解，ThoughtWorks的林冰玉有一篇文章很好的介绍了BDD的正确做法。如果将QA的外延扩展到在线的生产环境，制定合理的测量指标，调整测试策略，强烈推荐林冰玉写的另一篇文章产品环境中的QA。

　　其他职责

　　事实上，软件生命周期中有很多的活动，有很多处于灰色地段。既可以说是应该开发做，又可以说应该QA做，甚至可以推给其他角色(比如OPs)。不过我们知道，一旦涉及角色，人们就再也不会按照全局优化的思路来应对问题了。这种灰色的活动包括：

　　持续集成的搭建

　　测试环境的创建于维护

　　UAT上的数据准备

　　代码中的测试代码的维护

　　测试代码的重构

　　在团队实践中，这些活动我们通常会让QA和开发或者OPs同事一起结对来完成。一方面避免知识孤岛的形成，另一方面在跨角色的工作中，也可以激发出更多不同的思路。

　　万能的QA?

　　虽然在这些活动中，QA都会参与，但是并不是说团队里只要有一个QA就可以了。QA在参与这些活动时，侧重点还是有很大不同的。

　　比如需求分析阶段，如果有QA的加入，一些从QA角度可以发现的有明显缺陷的场景，则可以在分析阶段就得到很好的处理。另一方面，尽早介入可以设计出更合理的测试计划(比如哪些功能的优先级比较高，用户更会频繁使用，那么对应的测试比重也会更高)。在Story分析与书写阶段，QA可以帮助写出更加合理的验收条件，既满足业务需求，又可以很好的指导开发。

　　在和开发一起编写澄清需求时，主要是编写自动化验收测试，而不是实际编写业务逻辑的实现(虽然QA应该参与Code Reivew环节，学习并分享自己的观点);甚至在上线运维阶段，QA还需要和OPs一起来设计用户数据的采集指标(比如用户访问的关键路径，浏览器版本，地区的区分等)，从而制定出新的测试策略。

原文转自：http://icodeit.org/2016/09/what-should-qa-do-in-a-agile-team/