第十二回测试驱动开发（2）

问题单可以形象地比喻为：你要寄一个包裹，这时候邮递员给了你一个单子，单子上有号码，你可以随时查看包裹的状态，以及有没有到达。只是在这里这个包裹里装的是一个问题。问题单的处理流程也体现了测试驱动开发的特点。首先测试人员发现问题，要开发人员确认，这是第一步。也即测试人员说：这个地方错了。研发人员要开始看，最后说确实错了。那这个问题就是有效问题，测试人员就有绩效了，因为测试出了问题。然后测试人员将问题描述清楚，比如写上电视机在开关八次之后，不亮了，开发人员唐伯虎确认的，然后这个问题就描述在一张单里，单就送到了开发部的PL，邱道长一看：哦，唐伯虎确认的。单就走给唐伯虎进行修改。唐伯虎一看：哦，确实是我确认的。修改完成，然后再发回邱道长进行审核，邱道长一看问题单改得不对，照这么改，改完开关七次就熄火了，还有这错了，那错了，就会打回来重改。如果没发现问题就走给业务专家进行审核，你改的问题涉及哪些方面都会有这方面的专家专门看你改得对不对，这个过程非常重要。业务专家如果发现问题，就再打回，你重新改，如果没发现问题就将问题的修改结果发给产品归档人员（英文名叫CMO）进行归档，这样修改就生效了。相当于你说电视机有毛病，这个零件坏了要换，那么归档人员一旦归档了，后面生^H小说产的电视机就按你说的这个零件来做了，可想而知如果你说错了有多严重。最后这张问题单就又走给了测试人员，在产品的下一个版本中，看你改得对不对，比如电视机再开关八次看看亮不亮，如果还不亮，麻烦就大了。因为让你改都改不对，这个罪名相当大，就像厨师做了一盘菜，品菜员说你做辣了，结果下一盘你做得更辣，你说这有多严重，基本上一年的辛苦就要付诸东流。因此从某种意义上讲测试人员掌握了开发人员的生死命脉（也可以认为质量就是开发人员的生死命脉）。问题单的流程确保了问题一旦发生不会丢失，因为一旦有问题单产生，始终有责任人进行跟踪，直到修改完毕走到测试人员那里。他测试完成发现确实修改了没有问题，这才将问题单关闭。问题单的这个修改跟踪的流程后来用在了快递业上面，发件人将包裹发出后，就产生了一个单号，这个单号可以一直查询该包裹的状态，确保了包裹不会丢失。各行各业都有自己的跟踪方法，华为的某位员工因为该跟踪流程去了一家物流公司，现在做到了副总裁的位置。测试驱动开发是成熟产品开发的重要模式，开发与测试的这种制约关系保证了产品的质量，以及修改问题的有效性。一个产品如果测试人员过于软弱，开发人员在处理问题的时候有着太高的话语权，一方面测试人员的劳动积极性就会受挫，另一方面针对缺陷的处理可能会放松，因此产品的质量就会产生风险。因此问题单是我们日常生活中处理问题的主要形式，作为一名开发人员，问题单的处理过程要经历几位重要的角色，他都可以宣布你的修改无效，甚至因此说你工作做得不好。他们分别是测试人员、PL以及问题涉及的相关审核专家。这就保证了一个问题的处理经过了重重的关卡，保证是有效的处理。这也让开发人员在处理问题单的时候，要经过三座大山。