由前面的文章可以知道，需求已經表達得很清楚，仍可能存在缺口與不一致之處。我們該如何在開發之前就發現這些問題，而不是之後才發現？我們要如何確保需求的正確性和完整性、是否在每次開發前，就能確認呢？要怎麼做到？

之前曾經過人家講個笑話，需求文件中最重要的資訊，不是完整的需求文件本身，而是撰寫該文件的那個人的電話號碼。如果找不到那個人，需求文件本身黑的，都可以說成白的。

圖 4-1 以前最重要的不是文件，而是寫文件的人的聯絡方式

不知大家聽過 Gerald Weinberg (傑拉爾德·溫伯格) ，他是美國軟體工程界最著名的人士之一，也是電腦軟體開發以及心理學與人類學領域的作家與講師。他在《Exploring Requirements》一書中寫道：
檢查需求最有效的方法之一是使用測試案例的精神，來描述需求要做什麼。

圖 4-2 軟工界大佬 - Gerald Weinberg (傑拉爾德·溫伯格)

你會說：「David，大佬說的每個字我都懂，但是合起來不確定他想表達什麼？」。

你知道測試案例裡面最重要的元素是什麼嗎？就是「輸入資料」、「執行步驟」、「預期結果」。「執行步驟」大家都知道，就是你想要怎麼來操作受測系統，來進行測試。那其他兩個呢？

輸入資料就是在進行測試時，你打算餵給受測系統的資料。一般人不太會注重它，例如你可能只是會說要讀入兩個數字，但是輸入2和3，跟輸入0和-1，你覺得哪一種找到錯誤的機率大呢？

預期結果則是另一個會被忽略的項目，很多人會說就是寫受測程式要沒有問題。讓我們來看看一個範例，假如你要測試一個系統的安裝功能，你覺得怎樣叫做安裝成功呢？你會怎麼寫預期結果呢？

以下是一些常說的答案：

「一直按Next，直到最後出現OK，或是成功為止。」
「最後可以成功登入進系統。」
「安裝完後可以成功操作系統某項功能。」

你知道我之前遇到的測試人員會寫什麼嗎？

複製132個檔案
建立27 registry key
會啟動 7 個 processes
所有檔案的 checksum等於多少 …

聽到這裡你就可以知道，為什麼他抓得到Bug，而你可能抓不到Bug。你們兩個檢查的詳細程度不同，很多人都是在有做的程度，但是專業的測試人員是要做好做對。

你有沒有注意到，他列出的這些細項，其實都是受測系統要做的功能，他只是把這些需求完整列出，在執行完後逐一檢查。

所以Gerald Weinberg在這邊想要表達的是說，如果我們能夠用描述測試案例的精神，來描述需求，這樣就比較不會有模糊的空間。因為我們有具體的輸入值，明確地操作步驟，以及詳盡要檢查的預期結果清單。這樣需求很難被理解錯誤。

以這樣的觀念出發，在確認需求時，業務分析師經常與客戶一起討論，透過一些實際的範例來釐清需求，這些範例需要符合測試案例的精神來撰寫。確認業務分析師、客戶和開發人員都了解後，開發人員就可以去進行程式撰寫。到程式撰寫完畢後，把這些範例轉換成測試案例，來驗證所開發出的系統，是否能通過當初那些範例場景。

我們可以用下圖來表示這個觀念：

圖 4-3 實例化需求的概念起源

測試就是需求？

梅比斯環是一種只有一個面和一條邊的幾何形狀。你從任意一點出發沿著表面前進，會發現你竟然繞了一圈回到起點——但你已經在「另一面」了，卻又從來沒跨越任何邊界。

這正好對應到一種極致的開發境界：
測試＝需求，需求＝測試，兩者本質是一體兩面，彼此流動，不可分割。

圖 4-4 梅比斯環的極致 : 測試＝需求，需求＝測試

當一個團隊已經把「測試」不再視為驗證或事後補救的工具，而是當作需求溝通與對齊的語言時，就進入了「梅比斯環式開發」的境界。

在這個境界下：
 每一個需求都有範例來說明，這些範例本身就是測試案例。
 驗收標準不是在事後才定義，而是需求出現時就寫出來。
 測試不是 QA 寫的、也不是 RD 寫的，而是 PM + RD + QA 一起討論出來的。
 開發不再是「猜測需求」，而是「實作範例」。
 每個測試都不只是驗證程式，而是訴說業務邏輯與商業價值。

在這個過程中，PM、RD、QA 要怎麼一起努力？

這樣的流暢梅比斯環，不是自動產生的，而是三個角色通力合作的成果：

(1) PM：價值詮釋者與語境提供者
 描述商業目的與業務規則，提供「為什麼要這樣做」的背景
 幫助大家聚焦在真正有價值的例子，而不是隨機的輸入輸出組合
 將需求場景拆解成具體的驗收條件（例如：Gherkin）

(2) RD：實作引導者與技術轉譯者
 根據測試範例設計架構與模組
 提出技術上的可行性與邊界條件，協助補足測試盲區
 與 QA 討論該測什麼、如何自動化，並保證可重現性

(3) QA：風險感知者與品質守門人
 把需求範例轉成可驗證的測試腳本
 提醒場景覆蓋是否足夠：是否考慮錯誤狀況？邊界條件？使用者誤用？
 幫助團隊建立測試基礎設施與資料驅動策略

而當整個團隊都能用這樣的方式工作時，就等於進入了：
一邊寫需求，一邊驗證，一邊實作，一邊交付，一氣呵成的流動狀態。
這，就是現代軟體開發中最優雅的梅比斯環式協作。