/ ATDD

你什么时候翻薄饼?

Flipping pancake你什么时候翻薄饼?我们知道好的薄饼是什么样子的。两面有些棕色,边缘一圈白色。当你从一坨面糊开始,而整个餐馆坐满了饥饿的伐木工时,你怎么才能让你的薄饼达到这些需求呢?

这些需求非常明确,棕色的两面,白色的边。还有比这更简单的吗?下面让我们设计一个开发流程,能顺利得到符合要求的薄饼:

  1. 开发人员倒入面糊。
  2. 开发人员按时间表翻薄饼。
  3. 开发人员把“完成的”薄饼扔给墙那边的QA。
  4. QA检查薄饼。把不合格的薄饼扔回给开发人员去“修复”。
很明显,除非开发人员十分擅长估算,否则这个流程的结果就是一大堆浪费的薄饼,推迟的早餐,愤怒的客户,还有担心成本的财务会建议采用外包来开发薄饼。

好吧,让我们设计另一个不同的流程。观察做薄饼的过程,我们发现翻饼的最佳时机是最上面的泡刚破,表面开始开起来有点干的时候。

  1. 开发人员倒入面糊。
  2. 开发人员测试决定什么时候该翻薄饼了。
  3. 开发人员薄饼很好,交给QA。
  4. QA只需大概的观察一下薄饼。
当我们按这个流程做的时候,我们发现QA很少退回薄饼。做早饭也变得更有效率了。客户也开心了。考虑成本的财务建议减少QA了。

这个故事告诉我们:开发人员的工作直到通过验收测试才算完成了!

谁设计验收测试呢?当然是QA。

最近我读了Dennis Stevens的一篇博客 We Are Doing QA All Wrong。当然他非常正确。多年来,我们做QA的方式完全错了。确实,现在QA角色存在的唯一原因是开发人员工作做的不好。开发从来没有学习何时翻薄饼,所以QA在流程的最后。数十年前,经理们受够了开发糟糕的质量,在流程的最后增加了一个检查步骤。QA从此诞生了。QA这个角色加强了产生QA的不好的开发行为。因为QA在最后,开发人员不需要关心把事情做正确。开发人员不再担心Bugs;这就是现在Qa的角色。所有的开发人员需要做的事就是“说”代码目前就他们来看是没问题的,然后扔到墙的另一边。当你不用确保代码确实能正常工作的时候,最后期限就很容易设定了。
财务人员比较担心成本,管理层为了向财务人员证明QA的存在是有意义的,开始考核QA的工作效率。QA发现的Bug越多,他们的工作做的越好。注意这是多疯狂的事情啊!QA要想考核好的唯一途径是让开发搞砸。开发人员产生越多的bug,QA的工作就看起来越好。
逃避指责的邪恶联盟就此诞生了。开发人员交付垃圾代码从而满足截止日期。QA考核也不错,因为他们发现了大量bug。大家都很开心——除了最终的客户,以及担心成本的财务人员。
看,这不是火箭科学。如果QA的输入主要是在流程的最后,将会出现大量的浪费,返工,延期,还有愤怒的客户。
那么我们应该把QA放在哪里呢?如何才能破坏这个邪恶联盟,停止逃避指责呢?简单!把QA放在前面。
如果QA的工作不是测试产品,而是设计测试帮助开发人员了解何时翻薄饼,又会怎样呢?如果QA使用像FitNesse的工具创建了一系列自动化验收测试,开发人员就能知道他们何时算完成了。开发人员会一直工作知道验收测试都通过了。当然,这将会由开发人员来运行这些测试。
这就是好的敏捷团队的工作方式。QA(和开发)和业务人员一起工作来把需求定义成一系列自动化测试,开发人员来执行从而能知道何时他们才完成了。当所有的测试都通过的时候,QA对整个产品做最后的探索测试,然后送到生产环境。
最后一步其实说起来简单,做起来还是比较复杂的,但是不在本文章的范围。探索测试是一门技艺,需要持续的成为流程的一部分。
最后,你什么时候翻薄饼?“完成”的定义是什么?当QA设计的自动化验收测试都运行通过了,开发人员才算做完了。
 

 

这篇文章是翻译Uncle Bob的一篇文章,已经躺在我的草稿箱里有将近三年了,当年对这篇文章的理解仅仅只是讲TDD而已,现在的理解已经完全不是TDD这一小点而已了。最近发现邪恶联盟比比皆是,也不仅仅存在于开发与QA之间,很多公司的各个职能部门都是一样的。员工们在工作中产生的真正价值少之又少,大多数时间的产出都用于这些内耗。

实在是不愿这篇文章的价值隐藏在草稿箱中,特今天将其发出。