等別人都做好，我們才能開始嗎？

朋友公司的 RD 主管，對業務有不少意見。

有些需求，應該是業務先問清楚的；有些準備，本來就不該讓研發猜。這些話，我聽起來並不難理解。

但朋友接著提到，開發完成後，自己的測試也不夠，常期待其他測試團隊接手。

這讓我想到一件有點難承認的事。

我們看別人的缺口，通常比看自己的清楚。尤其前面的人真的沒有做好，更容易覺得，自己後面的辛苦都有了原因。

可是，一件事情有原因，不代表它就不需要被改善。

我不是想要求研發把所有測試都扛起來。專業測試有它的價值，需求沒弄清楚也真的要回頭補。只是這兩件事，也許不必等其中一邊先完美，另一邊才開始。

那支談團隊合作的短片，同時提到互補和各自承擔。我想到的是，如果每個人都需要下一個人幫忙，交出去的時候，能不能讓對方知道自己已經做到哪裡？

勤誠專訪裡談實作與缺陷的那一段，也讓我留下印象。要知道東西做得對不對，不能只停在完成了哪些動作，還得理解它原本應該怎麼運作。

放回朋友的公司，我想先挑一個功能就好。

請業務、開發和測試一起說說，客戶會怎麼用它。輸入正常資料，應該得到什麼？缺了一項資料，畫面又該怎麼回應？如果連這些都答不一致，先找客戶確認，也比做完再爭論早一點。

例如一個預約修改功能，這只是我拿來想像的例子：客戶改完時間，原本的預約會不會還在？選到不能預約的時段，系統會不會擋下來？畫面說儲存成功，重新打開，資料是不是真的改了？

如果這些是已經約好的行為，開發交出去之前，就應該先走過一次，留下版本、測過的情況和結果。還沒處理的問題也寫明白，而不是只留下一句完成了，讓測試的人重新猜。

需求還不確定的地方，則標出來，找掌握客戶資訊的人確認；如果 RD 直接和客戶談，就把確認結果留下來。不用硬把所有疑問都繞回業務，也不能因為文件沒寫，就當作不必處理。

測試團隊仍然需要獨立驗證，找開發沒想到的組合、邊界和回歸問題。開發的自測不是取代 QA，而是別讓 QA 的時間，一直花在第一次操作就能看見的缺口。

這樣一來，接手不是重新摸索整件事，也不必靠出錯才知道這一版改過哪裡。

我想像，最有價值的可能是修完之後留下的那個例子。把重現方式、修正和檢查結果連到同一張工作單或 Git 的變更紀錄；適合自動化的，再留下回歸測試。下次改到附近的功能，不必又靠某個人記得。

朋友身為 CEO，也不能只追加一句品質要顧好，時程卻完全不留驗證的空間。如果真的來不及，就一起縮小這次交付的範圍，說清楚哪些延後；不要把沒測過，默默改名叫先求有。

朋友現在看到的，還是兩邊互相不滿的樣子。我不能替他把結局寫好。

但我會想陪他試試看，讓兩邊各選一個自己能先補上的地方。

業務補清楚一個尚未確認的使用情境，RD 補上一段原本省略的自測，測試把發現的問題留下重現方式。下一次一起看，返工是不是少了，接手的人是不是不用再從頭問。

只要下一次交出去時，比這一次更讓人放心一點。

---

延伸參考：勤誠專訪：實作、缺陷與檢驗・團隊合作短片