敏捷中的qa会被取代吗?

随着业界对敏捷开发的逐步了解,经常有同事和朋友问我,你们现在敏捷里注重测试,所以每个人都在进行测试,甚至以前测试人员所认可的发展方向:自动化测试,都让开发人员参与了很多,那你们QA是不是会被取代呢?

听到这么一说,我真是猛然感觉到危机感,不过细想了一下,如果QA会被取代,就说明他/她的工作不重要或者不必要。既然这样,就还是从QA工作内容开始看看和分析吧:

  1. 让我们先从敏捷QA最早涉足的活动,业务需求分析入手。在业务分析阶段,QA可以通过自己的丰富知识,包括测试设计和分析的能力(例如实例化需求)来帮助业务分析人员以及客户发现遗漏的需求,以及从技术层面避免出现依赖等不合理的需求问题。
  2. 在开发过程中,虽然开发人员参与了不少的自动化测试的活动:单元测试和功能性测试等。不过这里需要说明的是:单元测试基本都是由开发人员负责完成的,更多的是侧重于代码中方法调用及模块调用这一层级的。而开发人员参与的功能性测试,更多的是从自动化测试实现方面出发的。究其原因,开发人员的编码技能一般来说都要熟练于QA。但是QA在这些活动中也在提供着自身不可替代的作用:根据单元测试,功能测试的完成度和覆盖率,更有指导性地规划项目中的测试金字塔;而且运用测试设计的能力,设计自动化测试的场景以及用例,以保证在最小最有效的测试场景和用例集中,完成尽可能高的功能场景的覆盖。我相信除非是像QA这样在测试设计方面倾注了很大的心血和时间,不然很难有能力设计这些架构和场景。而且QA也是可以写自动化测试的啊!
  3. 而在手动测试本身,基于自动化测试的覆盖力度,我们做得更多的是探索性的测试,而非基于明确的验收标准或者测试用例的验证性的测试。你也许会问那谁来做验证性测试,答案是开发人员、QA和业务分析人员一起在故事卡开发完成时来做的,而不是推到QA一个人的身上。对于探索性测试,QA采取了更有针对性和目的性的方法:根据对现有系统的理解和分析,归纳和总结出用户行为和功能点,然后以此为依据,开辟一段单独的时间,来对特定的行为和功能进行开放性的测试。这对于我们验收性的测试,是一种非常有效的补充。
  4. 在手动测试结束后,QA很多时候还承担了和客户沟通需求以及演示产品的职责,这样他/她们对于产品的认识有了更全面的了解,以及为什么需要这么做;同时客户对于他/她们的信任程度也提高了,从而更容易接受他/她们提出的建议。正因为这样,QA担任PM和IM也是很常见的。

除此之外,QA一般还会负责性能测试和安全性测试这些非功能性测试,以保证项目在各方面都有品质的保证。

在具体测试当中,QA发挥了关键的作用;在其他方面,QA也发挥了不可取代的作用。

  1. 首先,从项目整体上来说,对于项目部署和运维,QA也是很有发言权的。因为测试的过程中包含了这些部分。对于通过脚本部署产品,通过log分析和定位bug,QA对开发人员甚至运维人员都能提供帮助。
  2. 其次 ,在敏捷里,QA不仅测试的是产品本身,还需要对项目中的一切进行测试,这就包括了项目流程以及各阶段的分析工作。合理和优化的项目流程能帮助团队“更高、更快、更强”地达到目标,而QA有很好的全局观,所以很自然地会更关注于流程的优化。对于分析工作,敏捷的QA不仅仅是测试,更重要的是对现有结果进行分析和估计,有针对性地提出专业性的建议,便于项目组下一阶段目标的制定。

看到以上罗列的这些工作内容,有一个问题自然地会浮现在脑海里:“这么多工作,都是从理论上说的,QA能都做到吗?”答案你我都知道,不可能。实际项目中的QA能做到很大一部分已经很不容易了。但是就像其他角色一样,不可能在同时段时间内能做到所有的方面,但是我们至少知道了自己可以发展的方向,以及我们所特有的优势和技能。

敏捷中的QA因为要关注的方面更多了,所以有些可以代理出去的工作可以让其他角色辅助,而不必事必躬亲;但是我们自身所特有的技能,并不是能代理出去或者其他角色能轻易达到的。

如果下次有人在问我文章开头的问题,我会开心的告诉他:“欢迎你来取代我。”而他/她付出的会是“一万小时“的时间来成为QA方面的专家。到那时候,就不是取代我,而是成为我了。