很多人會以為測試個案就是測試活動 (testing) 的全部. 在真實世界中, 很多測試人員, 測試管理者, 或其他非測試人員, 會認為撰寫測試個案是測試人員最重要的工作, 會是他們最主要的產出.
所以測試的很多事情, 都會圍繞著測試個案來進行. 像是你寫了多少測試個案, 你執行了多少測試個案, 你的測試個案多少被自動化了等等. 所有你的考核也按照測試個案來. 所有對測試工作時程的評估, 也是根據測試個案的個數來決定. 這實在對測試個案太過看重了.
目前我已經很少用測試個案這個術語. 並且每家公司對測試個案的認知也不相同. 有的公司測試個案很詳細, 有個公司測試個案很簡略, 每家測試個案的詳細顆粒不同. 即使你有所謂寫得很好的測試個案, 也不代表你的 testing 做得很好. 這是兩件事.
就像 開發者一樣, 大家容易認為開發者只都在寫 codes, 事實上, 它需要進行分析, 設計架構, 更新 codes, 修復 codes, 討論需求等等. 並不是只有寫 codes 而已. 你不會認為 開發者只需要寫 codes, 自然測試人員也不會只是在 撰寫測試個案, 一樣的道理. 只是 codes 和 測試個案都容易被人家看到, 所以就容易以這個為追蹤和監控的中心. 因此, 測試人員就會想辦法把測試個案寫好寫多, 讓管理者和其他人知道你有在工作, 你做了很多事情. 管理者看到你寫了這麼多測試個案, 就會認為你很認真, 就會認爲這樣測試應該做的很好. 所以這個循環就會一直下去, 測試個案就越來越重要, 測試個案的數量就越來越多.
當然啦, 並不是測試個案本身是不好的, 他本身沒有什麼問題. 問題出在我們如果太迷念測試個案本身, 而忽略了測試活動中其他部分, 這就會有問題. 很多公司過於重視測試個案, 導致於測試人員花很多時間來撰寫, 維護, 和修改測試個案, 使得他們的 testing 很低效, 很緩慢.
所以我們應該讓測試個案本身, 回到他該存在的定位. 測試個案像是我們在測試活動中, 所使用的其中一種工具. 他就是一種工具, 並不是整個測試活動的全部. 測試個案不能定義整個測試活動的全部, 他只是測試活動中的一部分. 雖然測試個案是算蠻有用的工具, 可以讓我們在進行測試活動時很有效率. 但是測試本身, 並沒有強調一定要使用測試個案才能進行.
在以測試個案為中心的公司, 通常測試個案最重要, 測試人員只是執行測試個案的工具, 只要把測試個案寫好, 叫誰來執行都是一樣的. 所以設計測試個案的人很重要, 需要具備一些技能. 但是執行測試個案的人, 就不是那麼重要, 交給新手, 找個工讀生來做也可以, 或者是程式來做. 執行是不需要太多技能, 只要照表抄課就好.
此外, 在這樣以測試個案為中心的公司, 還會提到要根據需求來設計測試個案. 就感覺來說, 從需求中就很清楚, 很明確地得到測試個案, 你不用太用力也不需要什麼技能, 測試個案就在裡頭.
可是很少人會去談到測試活動中, 其他更重要的事情, 像是學習, 解釋, 探索, 和分析 等等, 需要人要發揮的地方. 這些需要人真正技能的部分, 往往很少被人提及, 包括一般書籍或是市面上的課程中, 也很少人有著墨到. 這是反而是測試行業中, 很重要重要的部分.
測試活動本身不是像工廠一樣, 可以按部就班, 可以明確步驟來執行. 測試就像是一場表演, 你需要有演技, 要有相關技能, 你才能產生出好的結果.
另外, 你怎麼知道這個產品還有沒有 bug? 撰寫完測試個案不行, 執行完測試個案也不行. 你只能不斷探索和實驗, 來幫助你提高信心. 所以是藉由執行來探索, 來了解受測產品, 這中間是需要技能的, 並且這個執行中不一定會先有測試個案. 你要從以測試個案為中心, 改成以執行為中心的文化.
在以執行為中心的文化裡, Testing 是一個需要技能的人, 來執行的活動. Testing 的目的是為了去發現重要的訊息, 關於風險, 關於產品狀態, 好讓我們的客戶基於此資訊, 來做出更好的決定.
Source:
(2) TEST CASES ARE NOT TESTING: TOWARDS A CULTURE OF TEST PERFORMANCE
(3) CAST 2014 Keynote - Test Cases are Not Testing: Toward a Performance Culture
全站熱搜
留言列表
