再谈敏捷QA

读完需要

6

分钟

速读仅需 2 分钟

发一篇几年前的老文。

曾经在《敏捷中的QA》一文里介绍了敏捷开发模式下，QA 如何参与从需求到测试的每个阶段，在每个实践中如何跟不同角色的合作，以及敏捷 QA 跟传统开发模式下的测试人员的区别等。

这些内容在今天依然适用，但在真实项目中往往情况比较复杂，总会听到一些困惑或者是质疑的声音。

在敏捷项目团队摸爬滚打多年以后，我想跟大家一起再来聊聊这个话题，下面逐个来分析我所见（听）到的质疑或困惑。

敏捷 QA 流程必须严格遵守

“如果 QA 没有参加 Kick-off，我们拒绝做 Desk Check；如果没有 QA 参与 Desk Check，我们拒绝测试。”

从需求分析到生产环境，推荐 QA 参与每一个环节，跟多个角色进行充分的沟通和合作。

有人把这个当做圣旨，觉得不管怎样都不能漏掉某个环节，但难免有特殊情况。比如，由于 QA 请假或者开会等，错过了某一次 Desk Check，一定要求等有时间了（甚至第二天或第三天）再补上，没准那个时候代码都已经上到测试环境，完全可以直接测试没必要在折腾大家来做一次全面的 Desk Check 了。

QA 参与每个环节的目的是尽可能早期发现需求或者设计中的不足，做到 Bug 的预防。如果已经错过了这个“早”，那就没有必要再纠结非要严格进行每个环节了，不然不仅没有意义，还带来浪费。

QA 不用了解太多的业务上下文，一样做的很好

“需求来的晚，QA 手头忙着测试当前迭代的 Story，根本没有时间去参与需求分析，不过这样也不影响，测好当前的卡就可以很好的保障质量了。”

这个想法是狭隘的。敏捷测试的原则之一是优化业务价值。如果连业务上下文都不清楚，如何做到优化业务价值？了解业务上下文的重要性不言而喻。

那么，真的忙的没有时间如何来破解呢？这其实是进入了一个恶性循环，需要找到突破点，打破这个不良环路，让其变成一个良性循环就好了。

不破不立，对于这个循环，就是需要减少测试 Story 的时间。可行的方案是：加强 Desk Check，确保单元测试的覆盖，保证开发验收完成到最终交付的代码在自动化测试的保护下不被后续环节破坏；同时 QA 参与技术方案的设计讨论，这样测试的时候就可以有针对性的测，必要时候辅助以 Bug Bash，由此节省出时间。经过两三个迭代的调整，情况定会有所改善。

技术方案讨论跟 QA 没什么关系

“技术方案，那是 Dev 们的事情，QA 的重要任务是如何做好测试，参与技术讨论浪费时间。”

知己知彼，百战不殆。如果完全不了解技术实现，很难做到有的放矢。正如前面提到的，QA 参与技术方案的讨论，了解更多技术细节，知道技术方案可能的风险，就能更好的指导测试，使测试更有针对性、更高效。

比如，对于微服务架构，了解了服务的熔断和降级机制，测试就能有效覆盖到相关方面。

单元测试 Review 没有价值

“单元测试还挺复杂，Dev 新人写起来都不容易，QA 更看不懂。QA Review 单元测试，提不出有价值的反馈，感觉是在浪费时间。”

敏捷 QA 有个实践就是在做 Desk Check 的时候 Review 开发人员写的单元测试，其目的是两个方面：

• 帮助发现漏掉的或者需要修改的测试，QA 更好的了解测试覆盖情况

• 帮助开发人员增加测试 Sense，同时也能帮助 QA 提高代码阅读和理解能力

我理解对于单元测试 Review 的质疑是由于 DEV 和 QA 的相关技能还有所欠缺的情况下可能会发生的情况，但并不能因此否认这个实践的价值。

这时正确的做法是 DEV 跟 QA 解释每个测试所测到的内容，而 QA 从业务的角度考虑有哪些 Case 是遗漏掉了的。经过一段时间的磨合，我相信 Dev 的测试 Sense 和 QA 阅读代码、理解测试的能力都会得到提高。

必须严格 Review 每一个单元测试

“我对 Dev 写的单元测试总是不放心，不严格的 Review 根本不行。”

另一个极端情况就是，不管花多少时间，认为必须严格Review每个测试，认真的去检查测试的每个实现细节。

对于复杂一点的Story，严格Review每个单元测试，我见过最长的是花了两个小时，到最后大家都已经筋疲力尽…这显然是一种浪费！

QA Review单元测试更多的是关注测试的覆盖情况，而不是关注每个测试的实现细节，后者更多的是属于Code Review范畴。更重要的是，任何实践都不能只关注形式，要看其价值，具体问题具体分析。对于新的团队新的人，可能刚开始需要多花时间去了解所写的测试。而对于成熟的团队，或者是非常有经验的Dev，这个Review过程可以简化，只看测试的标题，或者只是听 Dev 说一下测试覆盖到了哪些内容就可以了。

我一般要求整个Desk Check控制在 15 分钟以内，对于特别复杂的Story，最多也不要超过30分钟。

没有发现 Bug 的测试不是好测试

“这些自动化测试从来没有发现过 Bug，ROI 太低，没有存在的必要！”

由于有些测试执行起来太耗时、测试实现成本和维护成本都很高，大家在讨论要不要去掉这些测试的时候，总能听到上面那样的声音。

其实，自动化的回归测试并不是用来发现Bug的，有数字表明自动化回归测试发现Bug的比例仅有15%。自动化测试只是形成一道保护的屏障，增加对系统质量的信心。

敏捷团队的QA对质量应该有全面的认识，在制定测试策略的时候需要综合考虑多方面因素，要真正理解每个实践、每个活动背后的真实价值。

敏捷 QA 该怎么做？

关于QA的定义，有下面三个层次：

1. QA = Quality Assurance 质量保障第一个层次 QA 的要求是做好质量保障工作，确保我们交付给客户的软件产品是正常工作的。

2. QA = Quality Analyst 质量分析第二个层次的 QA 通过测试、数据收集的方式，分析系统的质量，识别风险，并反馈给团队，和团队所有成员一起确保交付的质量是合格的。

3. QA = Quality Advocate 质量倡导者第三个层次的 QA 不再局限于只关注质量，通过培养对产品和流程持续改进的思维模式、了解产品的整体质量视图和持续关注产品质量的意识，引导整个团队构建正确的产品，并且正确地构建产品。

敏捷QA需要做到第三个层次，通过分析软件风险并制定相应实践，确保软件在其整个生命周期中持续工作并创造价值，为业务和团队提供信心，从而为客户提供价值。

敏捷QA的所有实践和活动都需要以价值为核心来驱动，根据不同团队的具体情况可以适当调整，且在不同项目阶段应该也是演进式的。敏捷QA跟各个角色的沟通和协作，也是随着团队成员的了解程度、配合默契度不同而有变化，并不是要求一成不变的。