背景
“辉辉”：敏捷团队中的QA
“通通”：传统团队中的QA
----------------------开场-----------------------------
“辉辉”：“你们是怎么来确保软件质量的啊？”
“通通”：我们QA就是软件质量的守护神啊，我们正在努力建设完善的质量保证体系，通过早期的需求评审、设计评审，中期的测试用例设计、用例评审，后期的系统功能性测试、非功能性测试、回归测试、线上验证等层层把关，一系列流程来保证软件的质量啊。怎么样，牛吧？
“辉辉”：那你们是怎么处理开发过程中的需求变更的啊？
“通通”：最 恨需求变更了啊，总是变更那肯定是产品经理/需求分析师水平不行，小小的变更，得让我们所有流程再走一遍，身处下游的我们QA团队往往因此处于被动状态。 到时候由于变更产生的进度延迟，我们只能如实汇报，我们测试过程中做好记录，最后即使出现延迟交付或者质量问题，我们也好找出罪魁祸首。不能总让我们最后 一环的QA来承担这人，哼！
“辉辉”：那你们是怎么界定你们的测试范围的啊？
“通通”：口 说无凭，一切以文档为主，需求文档上没有写的，我们就不测；需求文档上写了实现方式是A，那么如果开发时安装方式B实现的，我们就提Bug，严格的按照文 档来，我们要铁面无私。虽然常常会有文档中漏掉的点，我们也会自觉的测试，但是这时候我们都会要求需求来邮件确认，总之，只有白字黑字说明的才可靠，你说 呢？
“辉辉”：那你们会做自动化测试吗？
“通通”：当 然了，我们通过selenium来实现终端的自动回归测试，目前我们都已经写了好几百个用例了，但是烦恼的时候，测试环境总是不稳定，用例回归失败率很 高，而且界面总是变来变去的，还得我总得修改脚本。所以目前我们正在研发一个很牛B的自动化测试框架，将来问题总是会克服的。
“辉辉”：看你做了那么多，又做的那么辛苦，那你觉得如何体现一个QA的价值呢？
“通通”：我 的价值可以用数据说话啊，缺陷库里那么多的Bug，还有那些自动化测试脚本，我们即将开发完成的自动化测试平台。想想都觉得自豪啊。可是也有些烦恼，常常 觉得测试在团队中没有很高的地位。而且年终总结会的时候，人家开发团队可以拿自己开发的对用户有价值的优秀产品来作为对于公司业务的贡献，可是我们测试团 队如果仅仅拿出上千个Bug或者上千个自动化测试用例来作为我们价值的体现，又觉得有些牵强啊，也许部门领导能看到我们的贡献吧，可是老板可不会关心你提 了多少bug，他要看你为用户产生了多少价值。这个有点麻烦(挠头)...
“辉辉”：嗯，不要气馁，我分享下我们团队是怎么做的吧。
1.软 件质量分为内部质量和外部质量，内部质量主要是指用户不可见的代码的质量，外部质量就是用户可见的外在表现。在我们敏捷团队里，每个人都要对质量负责，我 们QA不可能单独承担起质量保证的角色，因为谁都知道好的软件是构建出来的，也就是在需求、开发、测试都有很好的质量，才能够保证整体的质量。如果为了提 高质量，就一味的增加监控，最后会造成监工的比干活的多的局面，会打击团队的积极性，只会造成恶性的循环。
我们是一个Team，每个人都要对产品负责，对团队负责。从计划会议开始、到迭代的开发过程、每日站会、评审会议、回顾会议，整个过程中，我 们团队每一个人都要不断的做出决策，这个需求是否要做，这个Bug是否要改，取决于我们共同的决定。我们像对待自己的孩子一样对待产品，开发完成后会严格 按照约定好的完成定义做代码review、测试确认、产品确认，测试过程中也会充分的与产品、开发沟通，就是这样，我们来共同保证产品的质量。
2.在互联网时代，用户需求千变万化，因此我们拥抱变化。从一开始我们团队就不会做太多的计划和假设。在计划会议的时候挑选出优先级高的需求，拆分成足够小的能够快速交付到客户面前的需求，然后快速的试错，我们不过分相信分析和计划，更多的依赖于客户反馈。
当 然，要实现快速交付价值的前提是：拆分需求要做到具备独立的、便于沟通的、有价值的、可估算的、足够小的、可测试的这些特性。我们喜欢充分的沟通，只记录 下关键的测试点，而不是写长篇大论的测试计划、测试用例，那么应对起变化来，无论对于我们整个团队，还是我们QA自己，都会得心应手了。
3. 我们测试不是仅仅来源于需求，我们的测试开发工程师会通过工具扫描代码的质量，业务测试工程师会站在用户的角度来使用系统。有些需求本来就是我们自己提出 来的，因为我们总是找机会接触真正的用户，并且深入分析竞品的特点。别担心我们会抢走产品经理的饭碗，我们是跨职能的团队，团队内部成员之间的工作是没有 边界的。努力做到人人为人人，人人为客户。
4.我们用分层的自动化测试策略，尽量减少维护成本高的端到端的界面自动化测试，建立一个健康稳定的金字塔模型的分层测试策略。
通过我们的持续集成系统，对代码进行持续的编译、构建、测试（UnitTest）、审查、打包、部署。次级构建会执行较大的组件级别的测试或者UI自动化测试。我们的目标是及早的发现问题，及早的修复，把修复成本降到最低，并且持续生成潜在可交付的软件系统。
5.我们的价值用符合用户预期甚至超出预期的产品说话，开发过程中产生的缺陷数量、测试用例、测试工具等等这些对于用户来说都是没有直接价值的。我们的所有工作只有两个目的，要么通过站在用户角度进行探索性测试发现有价值的缺陷而直接服务于产品，要么通过开发测试工具或框架来提高团队工作效率从而实现服务于团队。
其实，我想说我不是QA，我是团队的一员，这就是敏捷团队。我具备专业的QA知识、做专业的测试工作，但是我也可以与产品一起确认用户故事的优先级，也可以与开发一起Code review、也可以耐心的回答用户反馈。
哈哈，是不是还有不少疑问？期待我们进一步的探讨和实践吧。
