測試能讓你同樣的錯誤不犯兩次

昨天我們說到了，那些有測試情境但沒寫測試的程式碼交付出去後會有兩種情況

• QA 沒找到問題
• QA 找到問題了

有 Bug 就把測試補上

第一個情況沒找到問題，那就不討論了，也可以不用在花時間去補寫測試。

第二個情況是 QA 找到問題了，這時我們就把測試補上。

這說起來很簡單，但想一想這種請況不就跟我們手邊那些沒有寫測試的專案，有 Bug 時我們想要加測試是一樣的嗎？

跟沒測試的專案的不同

那些專案我們之所以沒有加測試的原因就是因為我們改不動。為什麼改不動？是因為我們再寫程式碼時就沒有考慮要怎麼測試這件事，所以難改。

但這裡的情況二不同，因為這個狀況下，我們在這個項目上，已經花了 30 分鐘至少寫了一兩個測試了。

只是有些測試情境，我們因為時間的關係沒有寫，而會出問題的通常就是我們沒有寫的那些部分。

而這邊要加測試相對來說是比較容易的。因為我們再寫程式碼時有考慮到要怎麼測試，並且也有寫了一些測試。

修改 Bug 的流程

再來，因為它是 Bug，所以我們必需要修改。看到 Bug 的第一步並不是修改它，而是先證明它是錯的，再確保它被修改正確。而證明它是錯的和確保它改對的方法就是寫測試證明它。這個步驟大約是下面這樣

• 先寫一個測試證明目前的程式碼有問題。
  • 也就是 QA 所測出來的問題。
• 修改程式碼。
• 跑測試。
  • 如果失敗就繼續修改。
  • 如果通過測試，這樣就可以證明它被我們修正了。

有測試保護下，同樣的 Bug 不會再出現

而且因為有一個測試再保護這一個情境，所以我們可以保證，同樣的情境不會發生第二次同樣的錯誤。因為如果改壞了，測試就會失敗，這時我們就會知道並修正它。

如果我們有做到每個 Bug 都寫測試來保護，那我們就可以確定再交付給 QA 測試時，所有 Bug 都已經被修復，它們不會再出現。

也許你會想，這樣雖然可行，但離我們想要的專業不是還差很遠嗎？

是的，先承認我們還不夠好，再想辦法讓我們更好。我們就在這條路上不是嗎？