課後一位 IT 部門的女學員前來提問，「老師，我現在在公司負責一個專案，有個問題很困擾我，就是 user 每次都是到快結案的時候才開始認真測試，結果在最後一刻才回報大量的 bug，造成我們根本就來不及把這些 bug 解完，造成專案 delay，這我該怎麼辦啊？」
「為什麼你們專案的功能品質是要靠 user 測試呢？」
「因為我們 IT 部門只有幾位 QA 而已，根本就沒辦法測完整。」
「為什麼 QA 人力少就會測不完整呢？」
「老師，因為我們專案的時間都很短。」
「那如果給 QA 足夠的時間，是不是就可以測得完整呢？」
「還是要靠 user 測試才行。」
「為什麼？」
「因為有些 bug 只有 user 測得出來。」
「同樣是人，為什麼有些 bug 只有 user 測得出來，而你們的 QA 卻測不到呢？」
「ㄜ~~~這個嘛~~~ㄟ~~~老師，這我也不知道啦！」
「那我再問你，這些 QA 測不到的 bug 多嗎？」
「是蠻多的。」
「照我看來，你這些專案的 Test Plan，包含 Test Scenario 和 Test Case 應該是相當不足，不夠完整的，所以才會有這些『症狀』，你應該可以從這個部份去下手。 」
「那老師，我該怎麼做啊？」
「剛剛你不是已經回答過我了嗎？QA 和 user 聯手就可以測完整了，不是嗎？你應該要在專案規畫階段，就請 QA 和各個 user 密切合作，制定出專案所有的 Test Scenario 和 Test Case，盡可能擴大測試的覆蓋率，然後在專案的執行階段，要求 QA 要確實執行這些 Test Scenario 和 Test Case，你應該就不會再有這樣的困擾了才對 。」
「喔，那這樣我知道了。可是，老師，這樣 QA 可能就要測很久，那專案不就會 delay 了嗎？」
「為什麼 QA 要測比較久，專案就會 delay？這些測試工作不是專案的『必要工作』嗎？不是本來就該排進專案的甘特圖計畫嗎？」
「ㄜ~~~對！老師你說得沒錯。」
「看來你們在專案的規劃階段，並沒有把專案品質管理計畫做得很好。還有一件事我要提醒你們，你們憑什麼認為，可以把 user 當成 QA 來用呢？他們不是專案的『客戶』才對嗎？」
「對，他們是客戶，可是老師，需求是他們提的，他們也應該要測一下吧？」
「他們的確應該要測一下，不過那是因為，他們必須確定你們交出來的東西，有沒有符合當初他們提出的需求，不然怎麼決定能不能驗收呢？」
「老師你說的也對啦！」
「我再打個比方好了，如果你去一家餐廳吃飯，那你就是客戶，你點了餐（提出需求）之後，你不會期望餐廳端出來的菜『本來就該一定沒問題』的嗎？」
「對，那是餐廳本來就該做到的。」
「那你會幫廚房先『試菜、試味道』嗎？」
「當然不會。」
「那萬一你吃了餐，覺得有問題，你是不是可能一毛錢都不會付，搞不好還會到網路上去給負評，對吧？」
「嗯，的確有可能。」
「是啊！生活中這種例子比比皆是，為什麼我們在工作的時候，觀念卻都走樣了呢？」
「......」
我很幸運，一出社會當軟體工程師，就遇到一位很好的老闆，他教育我，「軟體的品質本來就是 RD 自己該負責管好的，QA 不過是為了協助 RD『確保』品質沒有問題的加強把關罷了。」這個觀念在我後來的管理職涯中，不斷被驗證，確實是軟體品質管理的有效心法。
在台灣，對大多數 QA 而言，他們並不了解軟體程式的內部流程和結構，更不知道程式碼裡哪裡可能有漏洞，這些部分對 QA 而言就像是一個黑箱（Black Box）一樣，因此，無論 QA 再怎麼努力測試，頂多也只能在軟體的外圍對它做 Black Box 測試，測試的有效覆蓋率會有一定的極限。
然而，這個 Black Box 對 RD 來說卻是不存在的，RD 是軟體的創作者，最清楚軟體的所有內部設計，能看到程式碼的漏洞在哪裡，所以 RD 有能力，也必須，對軟體做鉅細靡遺的測試，這也就是所謂的 White Box Test。
所以，唯有將黑箱和白箱這兩種測試相輔相成，才有辦法讓軟體的測試覆蓋率達到最高的境界，確保軟體的品質。
至於為什麼客戶要做測試，那也只不過是，為了決定「能不能驗收，付不付尾款」罷了。我們怎麼能期望客戶付錢給我們，還要花人力和時間「幫我們做測試」呢？我們怎麼還有臉「怪客戶太晚測出問題」呢？你不覺得這很奇怪嗎？
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
