作為一名研發人員，與測試人員打交道的機會是非常多的。研發人員與測試人員是製約與被製約的關係。可惜的是研發是被測試製約，原因很簡單:測試人員決定了研發人員出活的質量好壞(從根本原因上說，質量的好壞都是研發人員做的，測試人員隻是檢驗，從而讓其更好)。
測試人員的日常工作就是負責測試研發人員開發的產品是不是可用的，這就好比一個廚師炒了一盤菜，有專門的品菜員來嚐你炒的好不好吃，品完了再給客人上桌(當然現實中可能沒有這回事)。如果這個品菜員發現你辣椒放多了，那你就完了，弄不好一個月的菜都白炒了。如果品菜員沒有發現辣椒放多了，而客人吃的時候發現辣椒放多了，吃完了直打噴嚏，並因此大發雷霆，甚至叫人把店砸了，那問題就嚴重了。這時候這個嚴重的問題導致品菜員和廚師要各打50大板，這50大板是各打各的沒有任何關係，甚至廚師那邊如果不打，品菜員這邊也不管，他隻挨他的打就是了，也就是廚師與品菜員是屬於不同的考評體係。因此每個合格的品菜員在品菜的時候都想盡了一切辦法，千方百計挑毛病。
研發與測試的關係就是廚師與品菜員的關係，這時候你知道了品菜員有多麼關鍵，因為如果一盤不合格的菜上了桌，吃出問題麻煩就大了。因此品菜員大權在握決定了廚師炒菜的好壞。說研發一直被測試欺負一點也不為過，因為品菜員是菜品質量的最後一道關，他放過去菜就上桌了。對於產品來說，測試是產品的最後一道關，如果他沒發現問題，產品就往外賣了，如果用戶這時候發現問題，後果可想而知。因此測試可以對研發進行製約，提出質量上的各種要求，研發不服可以上訴，但是研發自己不具備對測試提出的問題拍板的權力，他隻有解釋的權力。
這就是著名的測試驅動研發模型，簡單來說就是測試說了算，他說這裏有問題要改，研發就要改，如果研發說不改，可以說服測試，但測試有拒絕的權力，如果研發仍堅持不改，那就要上訴。如果測試說不改(這種情況基本不存在，從上麵可以理解測試人員對產品質量的要求要遠高於研發，這就好比如果品菜員覺得這盤菜炒得好，那廚師可能不管真好還是假好，馬上上桌，所以品菜員一定要把握菜品的整體質量)，那研發一般默認。
所以研發人員受測試人員的製約。我在學習完三周兩天之後就開始正式上崗工作了。在日常的工作中我們主要做兩件事情:第一件事情是處理測試人員測試出來的問題或我們自己發現的問題，第二件事情是做新的開發。事實上新開發不常有，因此我們平時主要處理測試人員反饋過來的缺陷，也叫問題單。即測試人員發現問題後，將問題描述清楚，提一張單到研發這裏(這張單一直存在，直到問題被解決才能關閉，保證了問題一旦發現就會被解決，不會丟失)，研發開始看著單排查哪裏錯了進行修改。下麵我們來介紹一下問題單這個新鮮事物，因為除了開發新特性，我們平常就是在處理問題單。問題單可以形象地比喻為:你要寄一個包裹，這時候郵遞員給了你一個單子，單子上有號碼，你可以隨時查看包裹的狀態，以及有沒有到達。隻是在這裏這個包裹裏裝的是一個問題。
問題單的處理流程也體現了測試驅動開發的特點。首先測試人員發現問題，要開發人員確認，這是第一步。也即測試人員說:這個地方錯了。研發人員要開始看，最後說確實錯了。那這個問題就是有效問題，測試人員就有績效了，因為測試出了問題。然後測試人員將問題描述清楚，比如寫上電視機在開關八次之後，不亮了，開發人員唐伯虎確認的，然後這個問題就描述在一張單裏，單就送到了開發部的PL，邱道長一看:哦，唐伯虎確認的。單就走給唐伯虎進行修改。唐伯虎一看:哦，確實是我確認的。修改完成，然後再發回邱道長進行審核，邱道長一看問題單改得不對，照這麼改，改完開關七次就熄火了，還有這錯了，那錯了，就會打回來重改。如果沒發現問題就走給業務專家進行審核，你改的問題涉及哪些方麵都會有這方麵的專家專門看你改得對不對，這個過程非常重要。業務專家如果發現問題，就再打回，你重新改，如果沒發現問題就將問題的修改結果發給產品歸檔人員(英文名叫CMO)進行歸檔，這樣修改就生效了。相當於你說電視機有毛病，這個零件壞了要換，那麼歸檔人員一旦歸檔了，後麵生產的電視機就按你說的這個零件來做了，可想而知如果你說錯了有多嚴重。最後這張問題單就又走給了測試人員，在產品的下一個版本中，看你改得對不對，比如電視機再開關八次看看亮不亮，如果還不亮，麻煩就大了。因為讓你改都改不對，這個罪名相當大，就像廚師做了一盤菜，品菜員說你做辣了，結果下一盤你做得更辣，你說這有多嚴重，基本上一年的辛苦就要付諸東流。因此從某種意義上講測試人員掌握了開發人員的生死命脈(也可以認為質量就是開發人員的生死命脈)。