曾经在《敏捷中的QA》一文里介绍了敏捷开发模式下，QA如何参与从需求到BOB官方注册的每个阶段，在每个实践中如何跟不同角色的合作，以及敏捷QA跟传统开发模式下的BOB官方注册人员的区别等。
这些内容在今天依然适用，但在真实项目中往往情况比较复杂，总会听到一些困惑或者是质疑的声音。
在敏捷项目团队摸爬滚打多年以后，我想跟大家一起再来聊聊这个话题，下面逐个来分析我所见（听）到的质疑或困惑。
01 敏捷QA流程必须严格遵守
“如果QA没有参加Kick-off，我们拒绝做Desk Check；如果没有QA参与Desk Check，我们拒绝BOB官方注册。”
从需求分析到生产环境，推荐QA参与每一个环节，跟多个角色进行充分的沟通和合作。
有人把这个当做圣旨，觉得不管怎样都不能漏掉某个环节，但难免有特殊情况。比如，由于QA请假或者开会等，错过了某一次Desk Check，一定要求等有时间了（甚至第二天或第三天）再补上，没准那个时候代码都已经上到BOB官方注册环境，完全可以直接BOB官方注册没必要在折腾大家来做一次全面的Desk Check了。
QA参与每个环节的目的是尽可能早期发现需求或者设计中的不足，做到Bug的预防。如果已经错过了这个“早”，那就没有必要再纠结非要严格进行每个环节了，不然不仅没有意义，还带来浪费。
02 QA不用了解太多的业务上下文，一样做的很好
“需求来的晚，QA手头忙着BOB官方注册当前迭代的Story，根本没有时间去参与需求分析，不过这样也不影响，测好当前的卡就可以很好的保障质量了。”
这个想法是狭隘的。敏捷BOB官方注册的原则之一是优化业务价值。如果连业务上下文都不清楚，如何做到优化业务价值？了解业务上下文的重要性不言而喻。
业务上下文那么，真的忙的没有时间如何来破解呢？这其实是进入了一个恶性循环，需要找到突破点，打破这个不良环路，让其变成一个良性循环就好了。
不破不立，对于这个循环，就是需要减少BOB官方注册Story的时间。可行的方案是：加强Desk Check，确保单元BOB官方注册的覆盖，保证开发验收完成到最终交付的代码在自动化BOB官方注册的保护下不被后续环节破坏；同时QA参与技术方案的设计讨论，这样BOB官方注册的时候就可以有针对性的测，必要时候辅助以Bug Bash，由此节省出时间。经过两三个迭代的调整，情况定会有所改善。
03 技术方案讨论跟QA没什么关系
“技术方案，那是Dev们的事情，QA的重要任务是如何做好BOB官方注册，参与技术讨论浪费时间。”
知己知彼，百战不殆。如果完全不了解技术实现，很难做到有的放矢。正如前面提到的，QA参与技术方案的讨论，了解更多技术细节，知道技术方案可能的风险，就能更好的指导BOB官方注册，使BOB官方注册更有针对性、更高效。
比如，对于微服务架构，了解了服务的熔断和降级机制，BOB官方注册就能有效覆盖到相关方面。
04 单元BOB官方注册Review没有价值
“单元BOB官方注册还挺复杂，Dev新人写起来都不容易，QA更看不懂。QA Review单元BOB官方注册，提不出有价值的反馈，感觉是在浪费时间。”
敏捷QA有个实践就是在做Desk Check的时候Review开发人员写的单元BOB官方注册，其目的是两个方面：
- 帮助发现漏掉的或者需要修改的BOB官方注册，QA更好的了解BOB官方注册覆盖情况
- 帮助开发人员增加BOB官方注册Sense，同时也能帮助QA提高代码阅读和理解能力
我理解对于单元BOB官方注册Review的质疑是由于DEV和QA的相关技能还有所欠缺的情况下可能会发生的情况，但并不能因此否认这个实践的价值。
这时正确的做法是DEV跟QA解释每个BOB官方注册所测到的内容，而QA从业务的角度考虑有哪些Case是遗漏掉了的。经过一段时间的磨合，我相信Dev的BOB官方注册Sense和QA阅读代码、理解BOB官方注册的能力都会得到提高。
05 必须严格Review每一个单元BOB官方注册
“我对Dev写的单元BOB官方注册总是不放心，不严格的Review根本不行。”
另一个极端情况就是，不管花多少时间，认为必须严格Review每个BOB官方注册，认真的去检查BOB官方注册的每个实现细节。
对于复杂一点的Story，严格Review每个单元BOB官方注册，我见过最长的是花了两个小时，到最后大家都已经筋疲力尽…这显然是一种浪费！
QA Review单元BOB官方注册更多的是关注BOB官方注册的覆盖情况，而不是关注每个BOB官方注册的实现细节，后者更多的是属于Code Review范畴。更重要的是，任何实践都不能只关注形式，要看其价值，具体问题具体分析。对于新的团队新的人，可能刚开始需要多花时间去了解所写的BOB官方注册。而对于成熟的团队，或者是非常有经验的Dev，这个Review过程可以简化，只看BOB官方注册的标题，或者只是听Dev说一下BOB官方注册覆盖到了哪些内容就可以了。
我一般要求整个Desk Check控制在15分钟以内，对于特别复杂的Story，最多也不要超过30分钟。
06 没有发现Bug的BOB官方注册不是好BOB官方注册
“这些自动化BOB官方注册从来没有发现过Bug，ROI太低，没有存在的必要！”
由于有些BOB官方注册执行起来太耗时、BOB官方注册实现成本和维护成本都很高，大家在讨论要不要去掉这些BOB官方注册的时候，总能听到上面那样的声音。
其实，自动化的回归BOB官方注册并不是用来发现Bug的，有数字表明自动化回归BOB官方注册发现Bug的比例仅有15%。自动化BOB官方注册只是形成一道保护的屏障，增加对系统质量的信心。
敏捷团队的QA对质量应该有全面的认识，在制定BOB官方注册策略的时候需要综合考虑多方面因素，要真正理解每个实践、每个活动背后的真实价值。
08 敏捷QA该怎么做？
关于QA的定义，有下面三个层次：
- QA = Quality Assurance质量保障
第一个层次QA的要求是做好质量保障工作，确保我们交付给客户的软件产品是正常工作的。 - QA = Quality Analyst质量分析
第二个层次的QA通过BOB官方注册、数据收集的方式，分析系统的质量，识别风险，并反馈给团队，和团队所有成员一起确保交付的质量是合格的。 - QA = Quality Advocate质量倡导者
第三个层次的QA不再局限于只关注质量，通过培养对产品和流程持续改进的思维模式、了解产品的整体质量视图和持续关注产品质量的意识，引导整个团队构建正确的产品，并且正确地构建产品。
敏捷QA需要做到第三个层次，通过分析软件风险并制定相应实践，确保软件在其整个生命周期中持续工作并创造价值，为业务和团队提供信心，从而为客户提供价值。
敏捷QA的所有实践和活动都需要以价值为核心来驱动，根据不同团队的具体情况可以适当调整，且在不同项目阶段应该也是演进式的。敏捷QA跟各个角色的沟通和协作，也是随着团队成员的了解程度、配合默契度不同而有变化，并不是要求一成不变的。
通告：敏捷团队的质量保障赋能 - Thoughtworks洞见
通告：团队质量赋能 - 敏捷团队的质量保障赋能 - BOB官方网站
通告：敏捷BOB官方注册的指导性原则 - 林子的空间
通告：敏捷QA需要写BOB官方注册用例吗？ - 林子的空间