測試的目的是為了保證生產出來的產品滿足甚至超出客戶的需求。測試的角度要從客戶的角度分析客戶的顯性需求和隱性需求。所以，做好測試，你必須要清楚得掌握客戶的需求。要掌握客戶的需求，首先你得清楚你的客戶是誰？
傳統的客戶定義主要有三種：Customer、User和Operator。customer是和你簽訂合同的對方；user是使用你的軟件的單位 （點）；operator是操作者。一般：user和討論功能模塊，和operator討論操作場景，和customer簽合同。比如你要做個電信軟件， 跟你簽訂合同的customer就是這個電信公司；使用你的軟件的user就是各個電信營業廳；操作你的軟件的operator就是各營業廳里各個服務 員。
CMM里還有一個關于客戶的定義：“負責接收產品并且付給開發組織報酬的個人或組織。”
那么我們的客戶是誰呢？
答：
軟件質量可以從兩個角度看，Producer和Customer. 對應到樓主的定，Producer就是樓主的customer；Customer就是樓主的User和Operator。
從producer的角度看質量是：Meet the customer’s requirement the first time and every time.
從Customer角度看質量是：Fit for use.
測試的職責是縮小和彌合兩者的差距。用圖說明一下：
測試部門在SDLC的不同階段對需求的范圍和關注程度是不一樣的，是動態的。
SDLC 前期，比如需求分析階段，如果測試介入早，會去和producer和Customer做溝通，關注兩者理解的需求是是否一致。這個階段采用Static testing的方法，比如：Review， walkthrough. 這個階段發現的問題，解決的成本最低。
到SDLC中后期，假設Customer的需求都確定了，PRD和其他需求文檔定稿了。測試就會著重關注共同約定的需求，開始測試設計。我們就要確保producer做出來的東西和否和需求吻合。
問：
Tester必須比producer更了解customer，比customer更了解的producer，這樣才能更有效得縮小兩者的gap，對吧？
答：
‘Tester必須比producer更了解customer’，應該說是Tester要確保Producer理解的和Customer要的一樣， 如果Tester和Producer對某個需求有疑義，就需要Customer澄清確認。‘比customer更了解的producer’應該是成立的。 舉例如下：
第一階段：
當Customer的需求確定并記錄確認后，Business Prime（代表需求方-customer）產出BRD（Business requirement document），然后Business Analyst （相當于淘寶的PD，可以是customer方，也可以是Producer方）擴展細分后產出PRD。測試人員要通過Review/walkthough 等方式確保PRD和BRD一致，沒有脫節，沒有遺漏，無疑義。
第二階段：
PRD同時分發給測試和開發組，開發著手準備 SRS/SDS（Software Requirement Specifications/Software Design Documents），而測試開始準備測試計劃和測試設計。同時測試需要對開發的SRS/SDS評審，確保和ＰＲＤ一致。
以上都是Static testing. 屬于Independant Verification.
進入第三階段，摟主的表述‘比customer更了解的producer’應該是成立的，因為Customer不知道也不一定關心Producer具體是如何實現的。而測試去一定去了解和跟蹤。
這個階段，開發根據SRS/SDS開始編碼，測試開始設計測試用例。等編碼完畢，提交測試，測試開始執行測試用例。Validate and evaluate系統是否和PRD需求一致。
問：
跟進兩個問題：1、我們如何來保證Business Prime和Business Analyst一致？2、如何保證Business Prime與Operator Requirement 一致呢？
答：
1、Business Prime和Business Analyst可以不一樣，君子不器。但是二者的產出BRD和PRD必須保持一致。BRD中應當有一個需求列表，列出該項目，該階段應該滿足的用戶需求。 PRD對該表詮釋，細化，標準是Testable.如果測試人員認為某些需求太含糊，有歧義等，就要提出問題，直到測試人員接受，認為是 Testable。在這當中暴露的問題和gap，Business Prime有最終話語權。
2、為保持Business Prime與Operator Requirement 一致，客戶，開發和系統使用者可以使用以下方式溝通，確保Operator Requirement被正確理解。
a）用戶調查方式（Customer surveys）
b）JAD （joint application development） sessions – producer and user negotiate and agree upon requirements
c）讓用戶更多的參與到項目中（More user involvement while building information products）
d）前期建立系統原型和客戶溝通，有一個直觀認識（prototype）