所以研发人员受测试人员的制约。我在学习完三周两天之后就开始正式上岗工作了。在日常的工作中我们主要做两件事情：第一件事情是处理测试人员测试出来的问题或我们自己发现的问题，第二件事情是做新的开发。事实上新开发不常有，因此我们平时主要处理测试人员反馈过来的缺陷，也叫问题单。即测试人员发现问题后，将问题描述清楚，提一张单到研发这里（这张单一直存在，直到问题被解决才能关闭，保证了问题一旦发现就会被解决，不会丢失），研发开始看着单排查哪里错了进行修改。下面我们来介绍一下问题单这个新鲜事物，因为除了开发新特性，我们平常就是在处理问题单。问题单可以形象地比喻为：你要寄一个包裹，这时候邮递员给了你一个单子，单子上有号码，你可以随时查看包裹的状态，以及有没有到达。只是在这里这个包裹里装的是一个问题。

问题单的处理流程也体现了测试驱动开发的特点。首先测试人员发现问题，要开发人员确认，这是第一步。也即测试人员说：这个地方错了。研发人员要开始看，最后说确实错了。那这个问题就是有效问题，测试人员就有绩效了，因为测试出了问题。然后测试人员将问题描述清楚，比如写上电视机在开关八次之后，不亮了，开发人员唐伯虎确认的，然后这个问题就描述在一张单里，单就送到了开发部的PL，邱道长一看：哦，唐伯虎确认的。单就走给唐伯虎进行修改。唐伯虎一看：哦，确实是我确认的。修改完成，然后再发回邱道长进行审核，邱道长一看问题单改得不对，照这么改，改完开关七次就熄火了，还有这错了，那错了，就会打回来重改。如果没发现问题就走给业务专家进行审核，你改的问题涉及哪些方面都会有这方面的专家专门看你改得对不对，这个过程非常重要。业务专家如果发现问题，就再打回，你重新改，如果没发现问题就将问题的修改结果发给产品归档人员（英文名叫CMO）进行归档，这样修改就生效了。相当于你说电视机有毛病，这个零件坏了要换，那么归档人员一旦归档了，后面生产的电视机就按你说的这个零件来做了，可想而知如果你说错了有多严重。最后这张问题单就又走给了测试人员，在产品的下一个版本中，看你改得对不对，比如电视机再开关八次看看亮不亮，如果还不亮，麻烦就大了。因为让你改都改不对，这个罪名相当大，就像厨师做了一盘菜，品菜员说你做辣了，结果下一盘你做得更辣，你说这有多严重，基本上一年的辛苦就要付诸东流。因此从某种意义上讲测试人员掌握了开发人员的生死命脉（也可以认为质量就是开发人员的生死命脉）。