軟件驗收測試工作表

先寫出看得到的結果

請按已確認的用戶流程修改例子，並在工作副本加入實際結果、證據位置、負責人及決定日期。一項測試通過，只代表該項預期結果已確認，不能當作整個產品都驗收完成。

結果不符時，記下實際情況和可重現問題的最少步驟。先判斷是缺陷還是新增要求，再決定是否修改預期結果。修正後重做受影響的個案，也檢查相連的操作，例如拒絕一筆資料後，下一筆正確資料仍能匯入。

Cucumber 的 Gherkin 指引把測試情境分成事前狀態、發生的操作及可觀察結果。工作表也可沿用這個思路，不必因此採用 Cucumber；填好工作表亦不等於已建立自動測試。

相關資源

先交代事前狀態，再寫操作及看得到的結果，讓不同同事都能按同一要求驗收。

收到發票後，先核對必填資料和重複紀錄；資料有疑問便交同事覆核，不直接寫入會計系統。