文章

QA不是QC,兼谈Lean,Kanban与TDD(上)

如果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一起做完大餐后,要进行的除了一些探索性测试,只是验证一下放盐标准是否恰当而已(不恰当?改善它。)

 

下篇将从此篇理论出发,反省一下我所在团队Kanban的用法,顺便说说TDD。

画地为牢,还是勇敢开始?

 

scrumcn1387164103

Q:交付压力太大,根本没时间学习TDD,也没有时间做UT,如果要做,需要在排期的时候留出足够的时间!

A:写出有质量保证的代码,RD自己就是直接受益者,在投资收益关系如此清晰的情况下,你为什么还在犹豫?写不写UT,要不要用TDD的方式开发,要不要改变当
前edit and pray的状态,追求cover and test,是RD的个人追求问题,不是一个交付问题。

另外,需要反思,是交付压力太大了,还是交付能力太差了。

Q:需求变化了,功能代码要重写,测试代码也要重写?岂不是双重浪费?

A:功能代码不再适应当前的需求了,可以在测试代码根据需求改动后的第一时间收到反馈,这是不是一种浪费?如果是,那么,无法及时获取反馈,而产生的线上故障算什么?

 

作者:李大桃

原文地址:http://hi.baidu.com/whoistonyli/item/0d4959e2cc0f2afdea34c928

实施TDD时的常见问题

如果你刚接触TDD不久,可能一些常见的问题正在困扰着你:

  •  我该容忍多大限度的预先设计?
  •  在写测试的时候,可能必须构建出接口和一些类来让代码编译通过——这一步该跨多大?

Chad Meyers写下了一些他在开始接触TDD实践时碰到的疑惑和问题,它们应该都是比较常见的: Read more

如何做代码评审?

谈及TDD的好处时,其中之一就是随时随地的Code Review,所以,貌似TDD是不需要Code Review的。但实际上,TDD和Code Review是两个正交的维度,做TDD并不妨碍Code Review。 Read more

如何激励同事编写单元测试

摘要:从管理人员到开发者,每个人都在说单元测试,但是却很少有人执行。Lurkerbelow深知单元测试带来的好处,也积极提倡单元测试,但公司同仁却对此毫无兴趣。无奈之下,Lurkerbelow在Stack Exchange发出上“求救”,抛出《如何激励同事进行单元测试?》的话题。 Read more

解读TDD的五大误区

摘要:所谓TDD简单地说就是以下两个步骤:确保所有的需求都能被照顾到;在代码不断增加和重构的过程中,可以检查所有的功能是否正确。本文我们一起来看下关于TDD的五大误区。 Read more

矛盾:全部测试,除了Accessor类?

在Raikes学院的敏捷开发者技能课程上,我说我们通常不测试Accessor。但是我们不是可以测试所有的吗,这是不是很矛盾啊?
上周,我和切特, Cheezy参加内布拉斯加大学(林肯)Raikes学院的CSM 课程和一节敏捷开发者技能课。真是很有意思。在快结束的时候,大家提到一件关心的事,我决定提笔写写这个。 Read more

我的TDD经验

在我的职业生涯刚开始的时候,我曾经是一个编码人员,虽然我被叫做开发人员。我通常参与开发中小型项目和产品。在刚开始的几年,我把大部份时间都花在写代码和实现功能上面。虽然我尽了自己一切努力,但是我依然经常在项目上线或者交付给QA测试后,要经历一段十分艰苦的修BUG时期。结果,我开始和其他团队成员一起延长工作时间,然后挣扎着尝试把这些似乎永无止境的BUG修完。我们没日没夜地工作,甚至周末也需要加班,但是产出却总不尽如人意,可以说是非常糟糕。在每个版本发布后,开发团队总是会有很大的压力。 Read more

什么是测试驱动开发(TDD)

“只有不断地写代码来修复一次失败的测试。”这就是测试驱动开发,或简称为TDD。我们先编
写一个测试,然后写代码来使这个测试通过。我们会发现我们所能做的最好设计依赖于现有
的能让我们不破坏事情的测试。这个用于构建软件的方法鼓励好的设计、产出可测试的代码
并且使我们免于由于有缺陷的假设而过度工程化我们的系统。所有这些是由可执行测试的方
法来驱动我们设计的每一步这一简单动作来完成的,这样能够推动我们达到最终的实现。
Read more