我们先讨论一下在传统的瀑布模型下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?中详细讨论过这部分内容。