記得在讀研期間，企業導師曾經問過我們一個問題：“測試人員應該在何時進入項目中？”。彼時的我們尚未有實際開發經驗，憑想象都答道是開發完成以後。那位在軟件行業有着多年開發管理經驗的資深專家說道：“同學們，你們一定要記住我今天說的話，測試人員一定要在需求討論階段就參與到項目中來。”
當時我們聽到之後都有些驚訝，不知道測試人員在如此之早的時候就介入項目中能有多大的效益。及至工作多年，踩過不少的坑之後，再看Bob大叔在書中所提出的驗收測試觀點，終於明白當年企業導師那一番話的含義。首先是對驗收測試的定義，傳統看法認爲是在軟件開發完成之後對既有功能的驗證與檢測。Bob大叔認爲應該將這一概念前置爲需求的確認完成。
相信每一位碼農都經歷過需求變更的折磨，網上更有無數的段子調侃產品與開發的水火不容。其實這個難題並不是無解的，一個好辦法就是在開需求討論會時把測試人員也叫上。這樣當產品說“我這裏需要一個登錄頁面”時，測試就會對“這裏我具體要測什麼”提出疑問，在產品和開發的共同確認下在功能要求和技術實現上達成一致。
當然，這裏又會有很多的疑問拋出來說測試人員已經忙得不可開交了，就開發完成的功能都測不完，哪還有時間去參與需求呢？其實這個問題的根源在於測試人員的很大一部分工作是在給開發填坑，之前說過如果開發沒有以專業態度要求自己，開發過程中不做單元測試，開發完就扔給測試，這等於是在讓測試幫開發去做最基本的功能檢驗。這顯然是一種效率極低的方式，導致測試和開發把寶貴的時間都消耗在交流上了。
所以要從根本上解決問題則是開發要轉變態度，目標不是讓測試去找錯誤，而是要讓測試找不出錯誤來。一個很好的手段就是構建一套金字塔式的自動化測試體系。自塔底向上分別是單元測試、組件測試、集成測試、系統測試、人工探索式測試。
單元測試在前面測試驅動開發章節已經敘述過，是軟件系統的最底層實現邏輯。而組件則是在底層之上的獨立模塊。將多個功能相關模塊整合在一起又可以進行集成測試。系統測試則是最終完成的軟件功能，包含所有模塊的整體測試。以上這些工作都應該是開發人員與架構師完成的工作，這樣測試人員就可以解放出來參與需求討論，專注於軟件質量的相關工作了。