本文是「測試之外的那一半：一個 QA 回頭帶當年的自己」系列第 9 篇。

昨天講測試是抽樣。今天講更實際的那一半：時間不夠的時候，怎麼決定樣本取在哪裡。

不過我得先講一件我自己很難看的事。

我的「測完了」是靠什麼撐住的

有一天下午，我快把一個新功能測完了。正要補幾個邊緣案例、抓截圖、錄影、整理報告，測試站的登入服務掛了。

報告我還是交了，註明截圖等服務恢復再補。主管可以，PM 也可以，事情算過去了。

但那天晚上我卡在一個問題上，它跟登入無關，也跟截圖無關：

我真的測完了嗎？

我平常講「我快測完了」「主要 case 都跑過了」「我感覺沒問題」，講得很順。那天我才發現，我講不出「我覆蓋了哪些、沒覆蓋哪些」。

因為平常我不需要講。我可以一直回去點點看。 心裡卡卡的再跑一次，懷疑哪條流程沒測就再補一次。我的「測完了」是後驗的，是靠隨時能回去確認撐起來的。

登入一掛，那根支柱就垮掉了。

實習的時候也是這樣。差別只在那時候沒有任何事情逼我面對。

十分鐘寫一份測試計畫

我後來讀到 Jersey Su 的〈計畫趕得上變化〉，裡面引了 Google 測試工程前輩 James Whittaker 給團隊出的一道題：

給你十分鐘，寫出一份測試計畫。

Whittaker 接手 Google 部分產品的測試時，看到團隊花好幾週寫巨大的計畫文件，寫完之後沒有人回頭翻。所以他出了這道題：如果一份計畫有價值，那個價值應該在十分鐘內就浮得出來。

只看「快」會誤讀這道題。撐住它的是一套叫 ACC 的方法。

ACC：三個欄位

順序是關鍵。先問使用者在乎什麼，再拆系統有哪些部件，最後看這些部件提供什麼能力。能力排完優先級，力氣該放哪裡就浮出來了。

十分鐘寫得完，是因為你不是在生產文件，你是在回答三個問題。

我原本誤會了它的用途

我以為 ACC 是測試前用的：需求剛下來，QA 拿它排計畫。

登入壞掉那天，我看見另一個用法。它也是測完之後，用來審問自己的工具。

三個欄位一填，「我測完了嗎」就變成可以檢查的東西：

使用者在乎的屬性，我每一項都碰到了嗎？系統的每個元件，我取樣取到了嗎，還是全壓在同一塊？高優先級的能力我驗過了嗎，低優先級的那些，我是刻意跳過，還是根本忘了？

最後那個問法最有用。刻意跳過跟忘記，從結果看完全一樣——都沒測。從專業上看差很遠。

這也接回 Day 2 那三句話：能講出「我沒測什麼、為什麼沒測」的前提，是你一開始就知道自己在取樣，而不是測到哪算哪。

真的只剩十分鐘的時候

我會寫這四行：

1. 這次改了什麼（範圍）
2. 使用者最在乎哪一件事（屬性）
3. 這次改動可能傷到哪些能力，照嚴重度排（能力＋優先級）
4. 我打算不碰哪些，理由是什麼（取捨）

第四行最容易被跳過，也最重要。沒有第四行，那份東西只是一張待辦清單。有了第四行，它才是一個判斷。

順帶一提，第一行需要的資訊你未必拿得到——那就是 Day 3 講的資訊落差。拿不到的時候，Day 4 那個先立假設讓對方推翻的問法就是用來補這一格的。

帶走的一樣東西

交報告之前，花十分鐘回答三個問題：

使用者在乎什麼、系統由哪些部件組成、哪些能力最不能壞。

然後看你的測試落在哪幾格。空掉的那幾格，是你要主動講出來的東西。

明天聊：RD 說「我改好了，你測測看」的時候，那句話把什麼丟給了你。

延伸閱讀

• 測試站登入壞了那天，我才被迫面對：我真的測完了嗎？
• 問題驅動測試（PDT）：致命 Bug 藏在你沒問過的問題裡