寫到第七天，我自己回頭看前六篇，問題背後的問題其實是同一個。

六天，六樣東西

Day 1 我說「沒問題」，但不知道自己在保證什麼。
帶走的是：問一句「你會從哪裡開始懷疑？」

Day 2 我說「那部分我看過了」，而看過跟測過是兩回事。
帶走的是：回報的時候講三件事——我測了什麼、沒測什麼、為什麼沒測。

Day 3 同一句「這個要測一下」，在三個位置聽起來是三種意思。
帶走的是那五個判斷題，用來看自己實際在哪一種結構裡。

Day 4 對方講不出他要什麼的時候，我改成先猜一個版本給他改。
帶走的是：否認比生成容易。

Day 5 我拿第三階段的工具去解第一階段的問題，把自己卡死兩個月。
帶走的是：先問現在最大的不確定是什麼。

Day 6 我最得意的那件事，三個計分條件全缺，而且做成功的樣子是什麼都沒發生。
帶走的是：挑一件事，給它名字、結束點、還有一個知道那是你做的人。

這六件事底下是同一個問題

我實習的時候，以為測試的難處是「會不會測」。

六篇寫下來，我發現卡住我的東西幾乎都不在那裡。

主管問我程式碼交不交得出去，PM 講不出壓力測試要回答什麼，我自己把方法用在錯的階段，我做的事情沒有進到計分表——這些沒有一件是技術問題。

它們共同的形狀是：有人在擔心某件事，而那個擔心沒有被講出來。

主管的擔心藏在他的問句裡。PM 的擔心還沒變成一個問題。我自己的擔心藏在我對「做得好」的定義裡。連考績表也是一種擔心的形狀，只是它是整個公司的。

測試之外的那一半，大概就是這個：把沒被講出來的擔心，弄清楚。

弄清楚之後，那句「這個要測一下」才會變成一份你說得出理由的計劃。

但這只是四分之一

前六天講的都是怎麼看懂人。

從明天開始換另一邊：知道對方在擔心什麼之後，該做什麼測試？

這一週我會講一些更靠近手上的事——測試到底在幹嘛、時間不夠的時候怎麼排、怎麼證明一個 bug 真的消失了、測出一個空白的結果算對還是錯。

實習的我如果能先知道這些，大概可以少繞好幾個月。

明天見。