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

　　QA的职责

　　我们先讨论一下传统的瀑布模型下QA是如何工作的，其中最主要的问题是什么;然后作为对比，我们来看看在敏捷团队里QA又是如何工作的，工作重点又是什么;最后，我们详细看一看在新的职责下，QA应该如何做。

　　瀑布开发模型

　　即使在今天，在很多企业中，瀑布模型仍然是主流。每一个需求都需要经过分析，设计，开发，测试，上线部署，运维等阶段。虽然一些企业已经在实施敏捷开发，比如项目/产品以迭代的方式运作，也有诸如每日站会，代码检视等敏捷实践，但是如果仔细审视，你会发现其实开发模式骨子里还是瀑布：按照软件组件划分的部门结构(详见康威定律)，按照职能划分的团队(开发和测试分属不同部门)，过长的反馈周期，永远无法摆脱的集成难题等等。

　　随着软件变得越来越复杂，团队里没有任何一个人可以说出系统是如何运作的，也不知道最终用户是谁，以及最终用户会以何种方式来使用最终的软件。

　　更糟糕的是，按照职能划分的团队在物理上都是隔离的，比如独立的测试部门，独立的运维部门，整日忙碌而难以预约到档期的业务人员，当然还有经常疲于交付，无处吐槽的苦逼开发。由于这些隔离，信息的反馈周期会非常长，一个本来很容易修复的缺陷可能在4周之后才可能被另一个部门的测试发现，然后通过复杂的工作流(比如某种形式的缺陷追踪系统)流到开发那里，而开发可能还在拼命的完成早就应该交付的功能，从而形成恶性循环。

　　瀑布模式中的QA

　　在这样的环境中，QA们能做的事情非常有限。在需求开始时会他们参加需求澄清的会议，制定一些测试计划，然后进行测试用例的设计。有的企业会用诸如Excel之类的工具来记录这些用例。这些写在Excel里的，死的用例用处非常有限。而最大的问题在于：它们无法自动化执行。另外，在实际软件开发中，需求总是会经常发生变化，需求的优先级也会有调整，然后这些记录在Excel中的死的用例会很快过期，变得无人问津。

　　除此之外，QA中的有些成员会使用工具来录制一些UI测试的场景，然后在每个新版本出来之后进行回放即可。然而，当UI发生一点变化之后，这些自动化的用例就会失效：比如HTML片段中元素位置的调整，JavaScript的异步调用超时等等。

　　显然，这种单纯以黑盒的形式来检查功能点的测试方式是不工作的，要真正有效的提升软件质量，仅仅通过事后检查是远远不够的，软件的质量也应该内建于软件之中。QA的工作也应该是一个贯穿软件生命周期的活动，从商业想法，到真实上线，这其中的所有环节，都应该有QA的参与。

　　系统思考

　　如果不从一个系统的角度来思考软件质量，就无法真正构建出健壮的、让业务和团队都有信心的软件系统。质量从来都不只是QA的职责，而是整个团队的职责。

　　关于软件质量，一个根深蒂固的误解是：缺陷在开发过程中被引入，然后在测试阶段被发现，最后在QA和开发的来来回回的撕扯中被解决(或者数量被大规模降低)，最后在生产环境中，就只会有很少的，优先级很低的缺陷。

　　然而事实上，很多需求就没有仔细分析，业务价值不很确定，验收条件模糊，流入开发后又会引入一些代码级别的错误，以及业务规则上的缺陷，测试阶段会漏掉一些功能点，上线之后更是问题百出(网络故障，缓存失效，黑客攻击，操作系统补丁，甚至内存溢出，log文件将磁盘写满等等)。

　　在一个敏捷团队中，每个个人都应该对质量负责，而QA则以自己的丰富经验和独特视角来发掘系统中可能的质量隐患，并帮助团队将这些隐患消除。

　　我在ThoughtWorks的同事Anand Bagmar在他的演讲What is Agile testing- How does automation help?中详细讨论过这部分内容。

　　QA到底应该干什么?

　　本质上来说，任何软件项目的目标都应该是：更快地将高质量的软件从想法变成产品。

　　将这个大目标细分一下，会得到这样几个子项，即企业需要：

　　更多的商业回报(发掘业务价值)

　　更快的上线时间(做最简单，直接的版本)

　　更好的软件质量(质量内嵌)

　　更少的资源投入(减少浪费)

　　其实就是传说中的多、快、好、省。如果说这是每一个软件项目的目标的话，那么团队里的每一个个人都应该向着这个目标而努力，任何其他形式的工作都可以归类为浪费。用Excel记录那些经常会失效，而且无法自动执行的测试用例是浪费，会因为页面布局变化而大面积失效的UI测试也是浪费，一个容易修复的缺陷要等到数周之后才被发现也是浪费。

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