QA不是QC，兼谈Lean、Kanban和TDD（上）
2010-09-11 20:08 菜阿彬 阅读(2477) 评论(7) 编辑 收藏 举报如果QA总是在Verify的阶段发现缺陷。那么有缺陷的不仅是你的软件，更是你的流程——Mary Poppendieck。
有一家很糟糕的餐厅，里面的厨师几乎总是把盐放得过多。顾客少的时候，他炒好菜会自己尝一下，发现太咸了，就再倒回锅里再加工一下；顾客多时，就不管那么多了，直接上菜，然后等不能忍受的顾客把菜拿回来，再加工，而就算那些能忍受的顾客呢，下次也不会再来了。
这样的餐厅有见过吗？我是没有，只见过偶尔放错盐的，没见过这么天天放太多盐的。
但是这样的软件公司，却一大把，他们天天都在重复着下面的故事：
1， BA分析好需求。
2， Dev开始默默写代码，同时QA开始默默的设计Test Case。
3， QA测试Dev完成的东西。
4， 发现defect，打开defect跟踪软件，提交一条defect，并assign给相关Dev。
5， Dev看到有assign给自己的defect，open它、修复它、再把Defect Assign回给QA。
6， QA发现有fixed的defect，问Dev，这个修复已经打包了吗？可以测了吗？得到肯定答复后，开始测试。
7， 一般来说，测试是会通过，于是这个需求终于做完了。如果还是没通过，重复3—7。
有问题吗？跟餐厅一样，看情况。
如果没有或极少defect，那从1到3，就结束了，没什么问题。
如果defect很多、或者有些defect一次没修完、或者defect在今天修复，明天又重现，那么问题就太严重了——我们将在3到7循环很多次。
QA不是QC
关于QA，我们全搞错了！很多公司的QA，其实都是做着QC的活。那么QA和QC的区别是什么呢？维基百科里QC的词条里有一句概括:
Quality control emphasizes testing of products to uncover defects, and reporting to management who make the decision to allow or deny the release, whereas quality assurance attempts to improve and stabilize production, and associated processes, to avoid, or at least minimize, issues that led to the defects in the first place.
简言之，QC的工作重心在于发现defect，QA的工作重心在于预防defect。怎么预防呢？通过“改善和稳定生产、以及相关的流程”。文章开头的7步流程需要改善的地方，这是QA的职责和价值所在。
Lean
把生产领域中的Lean介绍到软件开发领域的Mary所著《Lean Software Development》一书中说：
如果你总是在Verify的阶段发现缺陷。那么有缺陷的不仅是你的软件，更是你的流程。
那么上面的流程究竟有什么问题呢？首先它存在太多的不必要的浪费，Lean第一原则就是“消除浪费”，Mary的书中介绍了7种软件生产中的浪费：
- Partially Done Work
- Extra Features
- Relearning
- Handoffs
- Delays
- Task Switching
- Defects
看看我们的流程：
- bug回到Dev时，Dev已经在做别的事了，他要停下来修复bug，这是Task Switching；
- 如果bug回来的晚，Dev都已经有点忘记他写的代码怎么回事了，需要Relearning；
- 如果修复bug占了很长时间，就留着那边Partially Done的需求；
- 而Dev把做好的东西转给QA、QA把defect提回来、修复后又转给QA，这是典型的Handoffs；
- 何况这一来一回，QA要等新的打包，这是一种Delay，尤其是对持续集成没有做好的组织；
- Defect本身就是一种浪费，因为他花了Dev和QA那么多宝贵的时间，却没有给用户增加Value。
7种浪费，几乎全占满了。
注：我的良师，中国敏捷软件开发实践的先行者之一，目前亚洲唯一一个CSC(与有荣焉)，曾告诫我说，不是所有浪费都要消除，比如Sprint中的Slack，松弛时间，就是一个好的敏捷实践；又比如，重构也是必要的浪费。但我觉得，对于一些浪费太多的组织，怎么强调“消除浪费”都不过分。
改进的流程
对于文章开头的流程，如果我们希望到第3步就结束，那也许会有很多需要改进的地方，比如代码质量、设计能力……，而从流程上，那么很重要的是第2步。
回头想想餐厅的例子，对于那个炒菜总是太咸的厨师，会有什么建议呢？很简单，我会建议他不要再炒完菜后才对放盐量进行检测，那已经太晚了，应该在事先制定一个大致的放盐标准（可以借助工具——勺子、经验、和其它厨师的交流……），以最大程度降低菜太咸的概率。
所以第2步里，QA设计Test Case和Dev写代码的行为，都不能“默默地”去做。QA不是到验证的时候才是主角，QA一开始就是主角。测试不仅是炒完菜后去尝，测试是QA在前期参与到Dev的开发工作中去，是与Dev沟通需求的验收条件，是提供QA的专业视角，帮助Dev开发出几乎没有defect的软件出来。
QA和Dev一起做完大餐后，要进行的除了一些探索性测试，只是验证一下放盐标准是否恰当而已（不恰当？改善它。）
下篇将从此篇理论出发，反省一下我所在团队Kanban的用法，顺便说说TDD。
