驗收「發佈文章就通知訂閱者」時,我們的測法是:拿一篇現成草稿,把它改成「已發佈」,看通知有沒有送出——有,通過。但客戶真正發文的動作不是這樣:他們是新建一篇、直接就設成已發佈。兩條路都通往「已發佈」,我們卻只走了好測的那條。
「改草稿為發佈」之所以好測,是因為那一列早就存在了——而這恰恰就是它避開 bug 的原因。真正的問題只在「新建的當下」才會發生(那一列還沒 commit)。我們挑了方便的路,也就順手把問題繞過去了,還誤以為測過了。
使用者不會照你方便的方式操作。他們會走最直接的那條——而那條,往往就是你沒測的那條。
測試要測使用者真的會走的那條路,不是你最好設定的那條。方便測的路徑會給你虛假的安心;真實路徑才會告訴你真相。





