今年有很多機會幫忙客戶處理軟體品質提升和測試執行效率的議題，每每檢閱各種資訊後總是感觸良深。
一般來說，軟體開發通常都會有測試，但多半會著眼在類驗收型的測試。這類測試通常是軟體開發的品質活動下限，畢竟你的交付對象不可能不驗貨。不過這類測試有個大家都知道的問題，那就是通常很晚期才會知道對錯，而且執行期會看起來很長，畢竟所有測試都在最後一刻統一驗收。一口氣驗出所有問題，然後解決問題，時間很難不長。如果再搭配窘迫的測試人員和資源，那問題就很驚人了。
通常想要改善這情況，有幾件事得思考：
降低最終測試案例數量。可以做的方式如只驗收影響的部分、等價類劃分、透過風險和覆蓋率因素來分散測項的執行或改良與刪除無效測項等。不過這些方式能否有效展開的前提在於對受測系統的功能與模組的掌握度和良善的測試案例管理。如果沒這兩個前提，那麼很難做好什麼減量的決策，畢竟沒有依據。
多樣的測試方式與早期測試，也就是我們常說的左移。在工程上，一個基礎的原則是 built in quality。簡單說就是在每個軟體開發階段都確保該階段交付物的品質，不讓瑕疵流到下個階段。話是這麼說，但想做好這件事卻很少有速解方案。以單元測試為例，或許會有一個單純的想法那就是從現在開始規定大家都要寫單元測試。通常很容易會觀察到兩種結果，那就是不了了之和施行效率不佳。接著就會開始常見的故事：
那麼到底是誰的錯呢？ 正解是整個開發系統的錯，或者非要說誰的錯的話，那大概就是全部參與者的錯。
為什麼是這樣的理由？如果組織在新產品或專案或團隊的一開始沒有左移測試的念頭或至少融入一些除了類驗收測試外的其他測試手段。通常亡羊補牢並不容易，因為組織內的工程人員和非工程人員早已經長期透過各種方式貼補或容忍品質議題，而這類慣性會成為引入所謂「正確」做法時的巨大阻礙。此外，從未考量類驗收型測試外測試的軟體系統要再為其撰寫其他類測試有可能是相當困難的事情，因為目前的軟體實作結構可能盤根錯節且沾黏嚴重(耦合度高)。面對這樣的軟體系統，一般做法都會從舊系統內的新實作開始落實。不過，這類施行方式會有幾個關鍵議題需要尋求所有該系統參與者的共識：
成效可能不容易立即彰顯，而且開發時間還變長了！畢竟既有系統的原有品質問題不會憑空消失，所以會產生一種雖然投資了品質活動，但怎還是有問題的現象。這類認知落差非常需要被重視和解決，否則可能加劇工程和非工程人員之間的摩擦。可能的解決方式不外乎事前溝通、對齊關注指標、或針對高度有問題的部分做一次性的改善等。
測試不只是學會工具就行。測試有時會需要軟體設計方面的知識，所以千萬別認為送人去學 xUnit 之類的工具，然後就要馬上雞犬升天。通常是會升天，但可能不是你想像的那種。因此，除了強化測試技術本身的學習之外，持續強化工程團隊在設計上的能力也是相當必要的。可能的進行方式除了培訓外，還可以考量組織內非正式研討活動和加深團隊對既有系統的理解等。
萬年不變的流程和政策造成的變革阻礙。此處的流程不只包含開發，還需要考量開發流程的上下游或分支流程。除非在意的只是有沒有某種測試技術活動，而成效次之，那麼的確還真不用想太多。若是希望這些活動能夠紮根並且持續發展和提升，那麼除了考慮工程相關流程外，最好也思考一下與該受測系統相關的業務流程或其他營運流程，同時重新審視這些流程所涉及範圍的政策，以便去除不必要的摩擦。
繼續閱讀
Augustin Lu
