不久前我換了辦公室座位，從獨立的 QA 部門被調到 PM 底下的部門。
職稱沒有換，事情沒變，產品沒變，我會的東西也沒變。但有一句話的意思變了。
「這個要做一下壓力測試。」
一個月前我才剛做過壓力測試，所以我知道該怎麼接。我照舊問：
「這次做壓力測試，是要回答什麼問題？」
PM 答不出來。他說的是：到時候上線，看預購的情況，大概就知道下個月會有多少人同時在用。
我當下沒反應過來哪裡不對。後來才想明白：我問的是一個技術風險問題，他手上的是一個日期和一個還沒發生的數字。
不是他答不好，是我拿舊位置的問法，去問一個坐在新位置上的人。
在獨立部門的時候，「這個要測一下」的意思接近：幫我在會議上講得出這塊的進度。
我的主管怕的是在會議上被問到答不出來。他不希望被問「為什麼那個大功能沒有測試」，也希望我們能多抓到幾個 critical 的 bug。所以我的回答會往「完整」的方向做：把範圍講清楚，把沒測到的標出來。
那個位置有一個真實的好處：打我分數的人，跟被我退件的人，不是同一批。 所以我說「這個不能上」的時候，不用擔心績效因此掉下去。
代價也很真實，就是穀倉效應。我不在開發的 sprint 裡，也不進他們的 stand-up。光是「這版到底改了什麼」、跟上一版有什麼異同，我就得自己去打撈，問 PM、翻 Ticket、看 git commit、對照上一版。
這些時間不會出現在任何人的估算裡，因為那不是別人的職責，但每次都要付出這段隱形成本。
而且落差不只在資訊量，還在時間點。
等我知道某個東西要改的時候，那個決定通常已經做完了。我能做的只剩驗收，不是參與——更別說測試左移，在決策還沒定案前就先介入。
這件事有一個更具體的形狀，我後來才看清楚。
如果你是 PM，你寫的文件通常是一份已經做完決定的文件。上面寫這個功能長什麼樣、有哪些欄位、什麼情況顯示什麼。它寫的是想要看到什麼結果。導入 AI 之後，還多半會貼心地附上 BDD 語句或驗收條件——文件看起來更完整了，但補上去的仍然是結果，不是意圖。
它很少寫意圖：我們為什麼要做這個功能、我們希望使用者拿它解決什麼問題、當初有哪幾個方案被否決掉。
但測試要驗的，恰好是意圖：這個產品，有沒有符合它當初被設計的期待。
所以當我手上只有結果、沒有意圖，我能測的範圍上限，就等於他們寫下來的那些。 我對這個產品的理解不深，就只能依照這份淺淺的理解去測。
等到出事，被問「你怎麼沒測到」，鍋還是給 QA 背。
這不是誰的惡意。
PM 寫那份文件的時候，他腦中的意圖已經內化成常識了，他不覺得需要寫。
這跟 Day 1 講的是同一件事：人很難解釋自己習以為常的東西。
到 PM 底下之後，同一句話的意思變成：
幫我在緊湊的時程內確認這個不會在上線的時候炸掉。
怕的東西不一樣了。這裡怕的是延期，是承諾出去的日子開天窗。
好處是我離決策更近了。
那些我以前要下海打撈的資訊，現在會自己走到我面前，
這個功能為什麼要做、哪裡是可以砍的、哪裡是絕對不能動的。
連那份沒寫出來的意圖，我也比較容易問到。資訊落差小了很多。
代價是測試範圍會被上架日期往回推算。
前置條件太麻煩、需要申請權限或要跨部門協作的測試，這類不好測的地方容易被放棄掉，不是因為不重要，是因為它排不進時程。
你會很常聽到「這個先不測，之後再補」，然後那個之後通常不太會來。
我剛換過去的時候，把這個當成退步，以前追求完整，現在被時間追著跑。
後來我覺得不是。這裡的工作換了一套定義：
在不夠的時間裡找出最多的風險，讓產品準時上架，同時清楚知道哪些小問題可以留在這一版。
最後半句是關鍵。「接受一些問題上線」跟「沒測到」是兩件完全不同的事。
前者是我知道有些地雷它就在那裡、我評估過它的影響、我講出來了，然後有人決定放它過去；後者是我根本不知道那裡有這顆地雷。
從真實的使用者的視角裡，兩者結果一樣：一個有問題的版本上架了。從內部團隊的角度來看差很多。
我第二份工作是第三種：掛在 RD 底下。我的直屬主管是 RD，Cross Functional Team，15 個人、8 個 RD，RD 負責開票，跟 3 位正職 QA 一起把 Ticket 做完。
那時候這句話的意思是：幫我確認我改的地方沒壞、而且能用。
這個結構有一個我當時完全沒發現的奢侈：「這次動到哪」根本不用查資料，開票的人就坐在旁邊。我後來要花好多時間去撈的東西，那段時間我只要看 git diff 就知道改成什麼樣子。
代價是沒有人在看商業價值。跨模組、跨流程，這個系統還能不能輸出一份正確的結果，這些有人在意；但使用者實際上為什麼要用這個功能、這個功能有沒有解決他的問題，不在任何人的檢查清單上。
而我最早的實習，其實是第四種：QA 在開發團隊裡，我的直屬主管是 RD。
跨功能性團隊，八個人、三個 RD，旁邊坐一個正職 QA，開票給我，每週在scrum 回報給其他人。
這個位置很特別：我離改動很近，同時又有人用測試的標準要求我。
Day 1 講的那個一眼看出我測試計劃缺什麼的主管，就是在這裡。
但我當時完全沒意識到這是一種安排。我以為那就是「軟體測試工作」本來的樣子。
《軟體測試實務》第一章把 QA 在組織裡的位置分成這三種。我讀到的時候第一個反應是：這三種我不是剛好都待過嗎。
把它們放在一起看，才看懂一件事：「這個要測一下」的意思，取決於說這句話的人擔心什麼；而他怕什麼，取決於他坐在哪裡。
PM 怕的是上線日到了東西還沒好，或者上了之後使用者在商店給一星。
RD 主管怕的是團隊交出去的東西被打回來重做。
QA 主管怕的是會議上有人問「這塊測過了嗎」，而他答不出來。
他們用不同的角度吹毛求疵，不是不信任你，是因為他們各自都有人要交代。
我實習的時候以為自己不懂的是測試。其實我不懂的是：我聽到的那句要我測一下，這句話背後所看重的事情是什麼，想知道，就得從哪個位置發出來的去回推。
你在哪一種結構裡，不是看組織圖，也不是聽 HR 怎麼說。用這五題自己驗：
- 你報的 bug 會被誰拒絕？那個人懂測試嗎？
- 你要在何時測什麼是誰決定的？他有沒有把測試時間算進去？
- 你說「這個不能上」的時候，誰會接受、誰會無視你？
- 你的績效是懂測試的人打的分數嗎？
- 你要花多少力氣，才能知道這次到底改了什麼？
第五題最能分辨，也最少被討論。那個力氣就是你的資訊落差，它會直接決定你測不測得到重點。
換結構這件事，比換公司常見得多。組織改組、部門合併、被調去支援另一條產品線，這些都會讓你手上那句「這個要測一下」換一個意思，而且不會有人特地跟你講清楚背後的脈絡。
所以這五題值得每隔一陣子重問一次。
明天聊第四件事：知道那句話從哪裡來之後，你可以怎麼把它翻譯成一份測試計劃。
iThome鐵人賽
看影片追技術