首页 > IT管理 > 热点

敏捷团队中的QA由来

◆ ◆ ◆◆QA,全称为Quality Analyst,即质量分析师(有些称为Quality Assurance,即质量保证师)。为什么它总跟质量扯在一块?感觉这个角

作者:水木清华 | 2017-01-04 13:28:17

◆ ◆ ◆ ◆

QA,全称为Quality Analyst,即质量分析师(有些称为Quality Assurance,即质量保证师)。为什么它总跟质量扯在一块?感觉这个角色明明做的都是测试的事情,为什么不直接叫做tester那?敏捷项目中的QA日常都做什么事情那?可能一大推问题都会冒出来。别急,跟着我这篇文章来一步步的回答这些问题。

◆ ◆ ◆ ◆

假设现在有一个保险公司,他想找一个软件公司做一个在线卖保险的系统。那么这个系统从开始到完成至少需要三个角色。

Business owner -> developer -> end user

Business owner即保险公司的人,也是我们的需求来源,由他来提出业务需求。

developer即软件开发工程师,根据客户的需求做出客户期望的产品,最终交付给客户。

end user即产品的最终用户,在本例子中即有意愿在网上买保险的人。这个系统到底好不好用,他们最有发言权。(有的时候end user和business owner有可能是同一批人,比如开发的是一个内部公司使用的OA系统)。


只有这些角色能够顺利、成功的完成一个产品吗?实际操作中肯定会遇到很多问题。这些问题会集中在两个地方。


第一个问题出在Business owner和developer。在沟通需求的时候他们彼此会发现太费劲了。Business owner张口就来的quote、premium、policy这些名词软件开发工程师不懂什么意思,因为他们没有保险行业的背景知识,而软件工程师喜欢说的MVC、BDD、Java之类的,Business owner也搞不懂,并且人家对这也不感兴趣。那么软件开发工程师想,如果有人能即懂得保险行业知识,又具有IT背景,那么分析需求肯定会顺利不少。这样的人在敏捷团队中就叫做BA(Business Anslyst,业务分析师)。BA会理解并挖掘客户的需求,然后将需求转变为具体的AC(验收条件,Acceptance critirial),再交由开发工程师来实现。同时他也可以将业务知识最大化的传递给开发工程师,保证开发工程师能够准确的理解需求(为什么不让Business owner直接将业务知识传递给开发工程师那?原因很简单,人家可是一秒钟几十万上下的主,那里有这么多闲工夫。)


所以系统从开始到完成变成了这个样子。

Business owner -> BA -> developer -> end user


另一个问题就出现在了developer和end user之间。开发工程师完成的系统能够直接拿给最终用户用吗?如果你说能,要么你是对自己的产品信心十足,要么就是盲目乐观。我想大多数情况是后者。因为开发工程师在将业务需求转换为编码实现时,一方面由于理解的问题,实现或多或少可能会与需求有所偏差。另一方面由于自身思维的局限性,会导致系统隐含了一些缺陷。假如最终用户在使用系统时,发现在线支付有问题,或者页面在自己所用的浏览器下不能正常显示,你觉得他们还有兴趣使用你的系统吗?这就相当于把最终用户当做系统的测试者,人家不收钱还帮助我们发现bug,那里有这好事?系统的问题要尽可能的避免暴露给最终用户。那么在软件开发工程师和最终用户之间应该再加一个角色,就是tester。tester的主要职责就是按照AC,对系统进行功能性测试,确保功能的正确性,另一方面是针对一些非功能性测试(比如安全性测试,性能测试),保证系统的健壮性。


Business owner -> BA -> developer -> tester -> end user


做到这些的tester还不能称之为QA,因为它的角色更像是软件质量的看门人,最终把关者,还达不到测试分析的要求。


现在新的问题来了,到底tester什么时候该开始对软件的测试那?


一个极端情况是等developer把所有的功能完成以后,再交给tester来测。这样会造成很多问题。


1、如果开发者需求理解有偏差,需要重新返工。

2、软件中发现了bug,该功能是很久以前开发完成的,developer定位和修复要花很长时间。

3、有太多的功能需要测试,tester要花很长时间,developer又要修复发现的bug,这段时间不可预估,虽然是属于项目上线的最后时刻,但是整个系统始终处于一个不稳定的状态。


大家都知道在软件工程中,需求变更发生的越晚,bug发现的越晚,会软件开发的影响会越大。这种极端情况的做法是不可取的。

72aaebf.jpg

那么应该怎么做那?我们可以将整个系统的功能细分成很多小功能点,每一个小功能点都是独立可测的,那么一旦开发工程师完成此功能点,tester立马就可以拿去测试。每一个小功能点就是敏捷中所说的用户故事(user story)。


一个user story的典型的生命周期是这样子的。

backlog -> BA将刚建好的story卡放置在backlog list里

Analyse -> BA细化story卡,完成验收条件等内容的编写

development -> 开发人员进行开发工作

testing -> 测试人员进行测试

UAT -> 用户验收测试,Business owner会对功能进行确认

Production -> Business owner准许后,将功能发布到生产环境


如果只是实现这样的流程,那么这个团队还不算是真正的敏捷团队,这里的tester也不算是真正的QA。因为业务需求通过Business owner到BA再到DEV到tester,是一个衰减的过程。小时候我们玩过一个游戏,老师让一群人排成一排,他会给第一个人说一句悄悄话,然后让第一个人偷偷讲给第二个人,第二个人再原封不动的讲给第三个人..直到最后一个人把这个悄悄话讲出来和老师的原话比较,我们往往发现最后一个人的话很难和老师的原话保持一致,甚至意思会大相径庭。那么这就意味着tester在做测试的时候他不一定能够真正了解业务的实际需求,所以在测试时难免会出现纰漏。这样的卡最后让business owner确认时,很难避免给business owner “惊喜”。


所以为了解决需求衰减的问题,tester要尽早的介入到的story的前期工作。在BA分析故事卡的时候,tester就可以根据卡的内容准备测试策略、测试环境,甚至准备测试数据。在开发人员领取卡的时候,tester可以从测试的角度给开发人员提供一些建议。而在开发人员开发卡的时候,tester可以和开发人员一起pair编写自动化的测试用例。开发人员开发完毕后,tester可以在开发人员的本地环境中快速验证其是否满足所有验收条件,必要的自动化测试是否已经完成等。在UAT环节,tester又可以帮助business owner进行sign off。


这个时候需求的传递已经不是一个简单的链式的行为,测试人员作为连接器把需求良好地串联了起来。测试人员的职责范围已经超出了我们通常所理解的范围。这个时候再用tester这个称呼已经无法涵盖该角色的职责了。所以就有了QA(质量分析师)这一角色。可以看出在敏捷团队中QA并不是质量的最终把关者,而是在项目开始就参与到了质量的控制当中,一直贯穿到所有环节。


【责任编辑:水木清华】