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来测。这样会造成很多问题。
如果开发者需求理解有偏差，需要重新返工。
软件中发现了bug，该功能是很久以前开发完成的，developer定位和修复要花很长时间。
有太多的功能需要测试，tester要花很长时间，developer又要修复发现的bug，这段时间不可预估，虽然是属于项目上线的最后时刻，但是整个系统始终处于一个不稳定的状态。
大家都知道在软件工程中，需求变更发生的越晚，bug发现的越晚，会软件开发的影响会越大。这种极端情况的做法是不可取的。
那么应该怎么做那？我们可以将整个系统的功能细分成很多小功能点，每一个小功能点都是独立可测的，那么一旦开发工程师完成此功能点，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并不是质量的最终把关者，而是在项目开始就参与到了质量的控制当中，一直贯穿到所有环节。
如果想了解敏捷团队中QA的具体职责，可以参见我司的同事的文章《敏捷中的QA》.
如果你想知道自己适不适合QA，请参见我司另一位同事的文章《敏捷QA，从入门到放弃》
