多年來，我在軟體開發過程中看到了許多不同的測試方式。每一種測試都有它的獨特性，一些開發人員認定他們自己有不只一種方式。在本文中，我試著列舉所有不同種類的測試，並說一說它們在專案上反映出的效果。
1. “我不是QA”（I’m not QA）
我提交程式碼，其他人驗證其是否能正常運作。我的工作就是寫程式碼，而不是測試。因為是我寫的程式碼，所以，我不能測試出程式碼什麼地方出錯了。我需要讓其他人看應用程式，並且學會如何使用，如何崩潰。通常，這種方式也說明缺乏說明文件，同樣原因，這應該是其他人的工作。通常這種測試方式意味著，質量是其他人該負責任的事。
2. “我沒時間”（I don’t have time）
我必須在3周時間內完成專案，再沒有時間去寫測試了。我想測試可以保證應用程式的質量，但是因為我必須三週內完成任務，所以我必須跳過開發中的這一部分， 直接做工作上的事情。一旦事情完成，我會做些手工檢查，然後直接投產。這種方式通常和那些只用1或2個月來開發，並且4年內不用維護的小專案相關，他們只需要短時間內得到一個產品。這種案例沒有說明文件，因為你沒有時間去做。（編注：關於這種型別，可參見伯樂線上職場部落格《每位開發人員都應銘記的10句程式設計諺語》一文中的“欲速則不達”。）
3. “管理故障”（Management fault）
許多大公司的僱員都遵循這種開發方式。他們有過失敗或專案推遲的經歷，因此，他們排斥一切不能給高層管理帶來直接利益的事。通常情況下，在持續快速地開發一個功能性強大的專案時， 在開始階段無需測試。隨著時間的推移，應用程式的增多，新增了越來越多複雜的程式，並且開發程式越來越困難。每一個新的部署就意味著大量的新錯誤和新任務。短短几年，應用程式失去可信度，通常有人想在新技術下重新寫程式。不幸的是，如果開發過程沒有改變，幾年後他們會在不同的技術中以同樣的方式結束。
4. “測試只是一個工具”（Testing is just a tool）
這種情形下，由開發人員編寫測試，但僅限於某些對他們編碼有幫助的地方。測試是用來作為創造新功能的工具，而非在程式碼中增加可信度的方式。如果任何新功能的新增破壞了已存在的測試，開發員會假定測試錯誤，測試需要更改、取消或刪除。雖然是對應用程式的測試，但是這些測試並不可信。如果這些測試不可信，應用程式也就毫無價值可言了。
5. “熱衷測試覆蓋率”（Test coverage maniac）
所有的一切都是關於程式碼的覆蓋率。使程式碼的覆蓋率達到100%是最終目標。檢視測試的覆蓋率以及檢視測試未能通過的地方，為那些路徑新增測試成了一項重複的工作。我的意思是，增加毫無意義的測試只是增加覆蓋率。測試將變得複雜，新開發人員通常要花很長時間才能明白這個程式碼是做什麼的。在這種情況下，我們就比其他人處於更有利的位置，測試不僅是和覆蓋率有關，還有可信度。
6. “可信度測試”（Test to trust）
這是終極方式。軟體開發的測試有許多目的，但是最重要的是在程式碼中建立可信度。如果隊員對測試有信心，他們會很自如地改進或更改程式碼。使其效率更高，質量更佳，週轉更快。
測試中有可信度並不是和程式碼覆蓋率有關，而是相信團隊成員，他們會為重要的事物增加測試。如果你做了更改或者破壞（break）測試，你就需要認真考慮你的更改，而不是僅僅移出錯誤測試。我們要做的是能提高程式碼和測試可信度，而非僅僅解決一個新問題。
這些年我瞭解到，測試是開發過程中至關重要的一部分。每次程式碼修改後，都應該進行測試。用於提高測試可信度的每一秒鐘，就是你每次執行測試都會成功的時候。在軟體開發上，取得最大效率的唯一方式不是不寫測試，而是相信你的測試。
你是一位開發人員嗎？你為你的應用程式寫測試嗎？你每次提交都在提高測試中的可信度嗎？每次提交都需要提高可信度，否則你就是增加了一個有問題的程式碼，最後終將導致你重寫整個程式。
相關閱讀：《程式出錯後，程式設計師給測試人員的20條高頻回覆》
譯文出處：伯樂線上
原文：Ramiro Rinaudo 翻譯：敏捷翻譯 – 祝佳
如需轉載，但請註明原文/譯文出處、譯文超連結和譯者等資訊，否則視為侵權，謝謝合作！