下载掌阅APP，畅读海量书库
立即打开
作为一名研发人员，与测试人员打交道的机会是非常多的。研发人员与测试人员是制约与被制约的关系。可惜的是研发是被测试制约，原因很简单：测试人员决定了研发人员出活的质量好坏（从根本原因上说，质量的好坏都是研发人员做的，测试人员只是检验，从而让其更好）。
测试人员的日常工作就是负责测试研发人员开发的产品是不是可用的，这就好比一个厨师炒了一盘菜，有专门的品菜员来尝你炒的好不好吃，品完了再给客人上桌（当然现实中可能没有这回事）。如果这个品菜员发现你辣椒放多了，那你就完了，弄不好一个月的菜都白炒了。如果品菜员没有发现辣椒放多了，而客人吃的时候发现辣椒放多了，吃完了直打喷嚏，并因此大发雷霆，甚至叫人把店砸了，那问题就严重了。这时候这个严重的问题导致品菜员和厨师要各打50大板，这50大板是各打各的没有任何关系，甚至厨师那边如果不打，品菜员这边也不管，他只挨他的打就是了，也就是厨师与品菜员是属于不同的考评体系。因此每个合格的品菜员在品菜的时候都想尽了一切办法，千方百计挑毛病。
研发与测试的关系就是厨师与品菜员的关系，这时候你知道了品菜员有多么关键，因为如果一盘不合格的菜上了桌，吃出问题麻烦就大了。因此品菜员大权在握决定了厨师炒菜的好坏。说研发一直被测试欺负一点也不为过，因为品菜员是菜品质量的最后一道关，他放过去菜就上桌了。对于产品来说，测试是产品的最后一道关，如果他没发现问题，产品就往外卖了，如果用户这时候发现问题，后果可想而知。因此测试可以对研发进行制约，提出质量上的各种要求，研发不服可以上诉，但是研发自己不具备对测试提出的问题拍板的权力，他只有解释的权力。
这就是著名的测试驱动研发模型，简单来说就是测试说了算，他说这里有问题要改，研发就要改，如果研发说不改，可以说服测试，但测试有拒绝的权力，如果研发仍坚持不改，那就要上诉。如果测试说不改（这种情况基本不存在，从上面可以理解测试人员对产品质量的要求要远高于研发，这就好比如果品菜员觉得这盘菜炒得好，那厨师可能不管真好还是假好，马上上桌，所以品菜员一定要把握菜品的整体质量），那研发一般默认。所以研发人员受测试人员的制约。
我在学习完三周两天之后就开始正式上岗工作了。在日常的工作中我们主要做两件事情：第一件事情是处理测试人员测试出来的问题或我们自己发现的问题，第二件事情是做新的开发。事实上新开发不常有，因此我们平时主要处理测试人员反馈过来的缺陷，也叫问题单。即测试人员发现问题后，将问题描述清楚，提一张单到研发这里（这张单一直存在，直到问题被解决才能关闭，保证了问题一旦发现就会被解决，不会丢失），研发开始看着单排查哪里错了进行修改。下面我们来介绍一下问题单这个新鲜事物，因为除了开发新特性，我们平常就是在处理问题单。问题单可以形象地比喻为：你要寄一个包裹，这时候邮递员给了你一个单子，单子上有号码，你可以随时查看包裹的状态，以及有没有到达。只是在这里这个包裹里装的是一个问题。
问题单的处理流程也体现了测试驱动开发的特点。首先测试人员发现问题，要开发人员确认，这是第一步。也即测试人员说：这个地方错了。研发人员要开始看，最后说确实错了。那这个问题就是有效问题，测试人员就有绩效了，因为测试出了问题。然后测试人员将问题描述清楚，比如写上电视机在开关八次之后，不亮了，开发人员唐伯虎确认的，然后这个问题就描述在一张单里，单就送到了开发部的PL，邱道长一看：哦，唐伯虎确认的。单就走给唐伯虎进行修改。唐伯虎一看：哦，确实是我确认的。修改完成，然后再发回邱道长进行审核，邱道长一看问题单改得不对，照这么改，改完开关七次就熄火了，还有这错了，那错了，就会打回来重改。如果没发现问题就走给业务专家进行审核，你改的问题涉及哪些方面都会有这方面的专家专门看你改得对不对，这个过程非常重要。业务专家如果发现问题，就再打回，你重新改，如果没发现问题就将问题的修改结果发给产品归档人员（英文名叫CMO）进行归档，这样修改就生效了。相当于你说电视机有毛病，这个零件坏了要换，那么归档人员一旦归档了，后面生产的电视机就按你说的这个零件来做了，可想而知如果你说错了有多严重。最后这张问题单就又走给了测试人员，在产品的下一个版本中，看你改得对不对，比如电视机再开关八次看看亮不亮，如果还不亮，麻烦就大了。因为让你改都改不对，这个罪名相当大，就像厨师做了一盘菜，品菜员说你做辣了，结果下一盘你做得更辣，你说这有多严重，基本上一年的辛苦就要付诸东流。因此从某种意义上讲测试人员掌握了开发人员的生死命脉（也可以认为质量就是开发人员的生死命脉）。
问题单的流程确保了问题一旦发生不会丢失，因为一旦有问题单产生，始终有责任人进行跟踪，直到修改完毕走到测试人员那里。他测试完成发现确实修改了没有问题，这才将问题单关闭。问题单的这个修改跟踪的流程后来用在了快递业上面，发件人将包裹发出后，就产生了一个单号，这个单号可以一直查询该包裹的状态，确保了包裹不会丢失。各行各业都有自己的跟踪方法，华为的某位员工因为该跟踪流程去了一家物流公司，现在做到了副总裁的位置。
测试驱动开发是成熟产品开发的重要模式，开发与测试的这种制约关系保证了产品的质量，以及修改问题的有效性。一个产品如果测试人员过于软弱，开发人员在处理问题的时候有着太高的话语权，一方面测试人员的劳动积极性就会受挫，另一方面针对缺陷的处理可能会放松，因此产品的质量就会产生风险。
因此问题单是我们日常生活中处理问题的主要形式，作为一名开发人员，问题单的处理过程要经历几位重要的角色，他都可以宣布你的修改无效，甚至因此说你工作做得不好。他们分别是测试人员、PL以及问题涉及的相关审核专家。这就保证了一个问题的处理经过了重重的关卡，保证是有效的处理。这也让开发人员在处理问题单的时候，要经过三座大山。