三個圓圈（3）：規格、程式和測試

June 08 17:04~17:35

 

時光飛逝，沒想到上次寫「三個圓圈」系列已經是去年6月底，轉眼過了近一年。昨天在整理「單元測試與持續整合實作班」的教材，翻出2003年Teddy在北科念書修軟體測試課程時劉老師所發的講義，看到上面這張圖，剛好也是三個圓圈，內容很有趣，今天來介紹一下。

這三個圓圈分別是：

• Specification：程式（系統）規格，也是期待結果。
• Program：實作出來的程式，這是我們實際可以觀察到的行為。
• Test Cases：測試案例，驗證程式與規格是否一致。
  

理想上，這三個圈圈應該要完全重疊在一起。但實際上大家都知道，幾乎不可能。因此就有幾個有趣的區間可以討論，也順便考考鄉民們：

1. 有規範的行為但沒有被測試到是哪兩個區間？
2. 有規範的行為且有被測試到是哪兩個區間？
3. 沒有規範的行為但卻有被測試到是哪兩個區間？
4. 有實作的行為但沒有被測試到是哪兩個區間？
5. 有實作的行為且有被測試到是哪兩個區間？
6. 有測試但卻沒有實作的是哪兩個區間？

***

由上圖可知：

• 有規範但沒有測試案例，代表測試不足夠。
• 有測試案例但沒有規格，代表：
  • 此為「莫須有」的測試案例，根本不需要。
  • 規格不完備，必須補寫規格。

這一點很有意思，在Teddy的經驗中，很多QA和程式設計師的爭議都來自於此。QA自認找到系統問題，但程式設計師卻認為這個測試案例根本亂測，測了一個系統不支援的行為然後跑來說這是一個bug，你說氣不氣人。通常這個問題來自於「不完備的規格」，或是「根本沒有規格」所以任由QA自己亂測，或是講好聽一點QA用「探索式」的方法來測試系統。如果雙方有互信，好好溝通也就沒什麼問題。但在大部分的情況都是以大吵一架、互看不順眼結尾。

• 有沒有什麼方法可以讓區域1變得越大越好？指派專人撰寫詳盡的規格書有幫助嗎？Design by Contract有幫助嗎？組cross-functional team有幫助嗎？BDD/TDD有幫助嗎？這些都是值得思考的問題。

***

友藏內心獨白：下一篇該不會又是一年後吧。