如果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种软件生产中的浪费：

1. Partially Done Work
2. Extra Features
3. Relearning
4. Handoffs
5. Delays
6. Task Switching
7. 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一起做完大餐后，要进行的除了一些探索性测试，只是验证一下放盐标准是否恰当而已（不恰当？改善它。）

上面说了QA与QC的区别，以及一种不太好的流程所造成的浪费，这篇对我所在团队的状况进行反思。

为什么这么多bug？

1个月200多个，按工作日平均下来1天10个，触目惊心。我认为原因很多，列举如下：

1. 环境。在进度第一的观念下，代码库中渐渐充斥着设计拙劣、充满陷阱的代码。殊不知慢就是快，而表面上的快实际上严重拖慢了团队的脚步。造成的结果不仅bug多，而且被fix后，不知哪天又冒出来了。
2. 程序员习惯。一个团队中的坏习惯比好习惯更容易传染，如果代码中到处都是不规则的命名、长函数、无用的代码、与代码不一致的注释、圈复杂度好几百，那么如果不是有特殊的动力，谁还有心情去写干净的代码？
3. scrum-but。比如，sprint结束没有demo，没有product backlog，没有user story。关于scrum-but，这边有ppt下载。好现象是，这些状况有很多改善。
4. 没有XP实践。现在有了code review，及其偶尔会有pair，但还非常不够。没有pair过的人是体会不到它带来的代码质量和产量的提升的。也很少有unit test，有不少test都不是“unit” test，因为他们依赖于数据库，或者外部文件，他们很少被运行。另外有些地方根本没办法写unit test，因为一个类的一个方法做了太多事，不够SOLID。
5. 没有持续集成。只有daily build，没有local build脚本。很多次发生代码库里的代码不能通过编译，却很久之后才被发现的情况。
6. 组织结构的问题。daily build是专门的CM部门维护，CM部门的人不属于我们的Scrum团队。而Scrum应该是one team，一个跨功能的团队。
7. 项目结构的问题。整个项目按模块分成几个solution，而每个solution都包含公用的十几个project。如果按solution来build，势必造成公用project的重复build。CM的daily build脚本是怎么处理的呢？它不build solution，而是依一定顺序，build所有的project。所以如果dev增加了一个project，脚本就必须改。——这样的脚本，实在没有把它拿来当local build脚本的心情。
8. VSS。我们是分布式团队，VSS服务器在上海，外地团队获取代码的时间要数个小时，所以他们几乎不获取。他们只在每周，由某人获取他们团队正在工作的某个solution（不是全部），然后其他人从他那copy。团队的代码永远都是过时的。这样的情形延续了两三年，在最近终于转向了SVN。SVN不是目的，只是Check in dance的基本前提。
9. 流程。那么多bug，可是我们应该责怪的不是团队成员，而是流程。在上篇文章开头提到的流程，真实的发生在我们团队。

kanban

我们以Scrum为框架“使用”敏捷已经近三年了，但是“使用”一词只能加上引号。因为很长一段时间，都没有user story；没有代码集体所有；QA和Dev以及Dev之间交流太少……为了强化团队成员在开发期间的交流，也为了促使PO写出更小的story，我们前一阵做了一个尝试：尝试不再拆task，领到story后直接做，把拆task时的讨论，从plan meeting延后到真正写代码的时候，避免写代码时单兵作战。——其实这时非常适合pair，可惜……。（有奖竞答：在中国的软件团队实行Scrum，最大的障碍是什么？）

没有task，带来一个相关的改变，就是scrum board的改变，我们引入了kanban的一些理念，改变后的白板如下：

白板很简单易懂：story就是plan meeting上团队commit的所有story。dev开始写代码时，移到development一列的ongoing，同时QA设计test case。代码完成（一般QA的case也完成）则往右移到done。然后QA开始测试时，把它移到verify中的ongoing，所有test case通过，则往右移到done。最后PO检查一下，如果没有问题，则放到最后一列Live！另外，development和verify都有WIP的限制，分别取得是dev人数+1，QA人数+1。

一切很完美，直到bug的出现：QA在verify的时候，如果有bug怎么办？而且如果这是development列的WIP已经达到限制了，有bug的story怎么办？把development列的1个story往左移，再把有bug的story从verify移回到development列？这是个好的开始。我的意思是，kanban的一个目的达到了——它把潜在的问题可视化了。

既然问题出现，就应该解决。回想上篇文章的内容，解决办法很简单——既然有QA的test case，那么在verify的阶段，为什么要出现bug？dev写完一个story，在没有通过test case检验的时候，就把它扔给QA，同时自己去开始编写下一个story的代码。——这是典型而常见的错误流程。为什么在development的时候，就把“代码写完+case通过”成为done的条件呢？是的，但就这个改变来说，bug不会少，但是bug的发现会提前，并且减少了dev和qa之间的往返。

因此我的想法是把白板改为如下：

当然白板的微调只是表象，需要调整的是流程，是观念，是test first的理念。

什么是TDD

TDD在很多人眼里是可望不可即的，它需要很高的技能，其实这样想的人也许对TDD有些误解，很多人以为TDD的T只是Unit Test。其实不是。TDD是测试驱动，这里的测试包括unit test，也包括验收测试。在scrum中，每个story都有“验收条件”，QA正是以此为蓝本来设计test case，设计出来的test case其实就是story的“验收测试”。那么我们以此“验收测试”来驱动我们的开发，不也是TDD吗？虽然我们还写不出自动化的验收测试，我们不会用FIT或者Story Teller或者Spec Flow……，但是，如果QA在设计test case时即与Dev保持沟通和思想碰撞，用test case来指导我们的代码编写（而不是在代码完成后用来“发现”bug），我认为，这也是一种TDD，是最廉价却同样有效果的TDD。在练习TDD技能的同时，不要忘了TDD的一种简单定义：TDD is a technique where teams use short development iterations based on pre-written test cases.

怎么样减少bug？

文章开头列出的那些问题，如果都解决了，bug是不是就减少了？也许，而且那只是我看到的问题，也许是对，也许是错。重点是团队养成反省，发现问题和学习的习惯。