15個軟體測試最佳範例
本文資料出處：http://www.cio.com.tw/article_in.aspx?aid=74&pg=1
在開發過程中儘早 讓測試人員參與
HomeBank Mortgage副總裁與品管部門主任Nathan Hayward表示，早在開發人員都還沒開始撰寫程式─也就是需求成形之前，他的品保（QA）員工就已和業務分析師，以及公司使用者會商過，以便決定測試項目的需求，然後再依每項需求開發測試案例（test case）。
為整個開發流程，建立品質查核點（checkpoint）或里程碑（milestone）。
eBay品保部門副總裁David Pride表示，這些里程碑是該公司在開發及測試小組中，推動品質文化的一種作法。在實地撰寫程式之前，QA及產品開發小組，會一一檢查這些要求，然後設下第一個里程碑。而在開發完成之前，eBay產品開發及專案管理小組，就會檢查QA測試計畫有沒有達到要求，然後再設下第二個里程碑。而第三個里程碑是設在QA測試開始前，這時開發小組要向QA展示他們所開發的程式，已經符合所有功能及業務需求，也在開發環境中通過初步測試；然後再將程式轉移給QA小組，進行下一階段的測試。
撰寫技術指南。
「軟體測試中有許多問題會發生，是因為人們不知道事情該怎麼做，」Stat Farm Insurance技術小組Claims主任Mike Fields說。為了要提早預防、追查軟體bug，State Farm的Claims小組IT員工發展出一套技術指南，提供許多的實用建議、模板、文件記錄，以及如何處理的相關資訊，告訴他們一個設計、開發及測試活動，應該怎麼做才對。如果Claims 的IT人員，對某項工作有任何疑問，都可以查閱這份技術指南，以找到相關解答。
集中你的測試團隊
在Hartfort's Property & Casualty Company，那些做功能性測試（也就是測試系統與應用軟體功能，而非bench-testing、可用性測試及整合測試）的員工都被編到同一組。該公司科技基礎架構小組助理副總裁John Lamb說，功能性測試人員，一開始會直接分派到各個專案中，等負責的特定專案完成，再回到中央小組。把測試人員集中起來—而非就應用領域分配給測試人員—可以確保他們能在專案結束後，相互分享最佳範例及學習到的經驗。Lamb說，要是不把人集中起來，測試員就會各有各的方法，這樣一來，要彼此分享從專案中學習到的經驗，就會困難許多。
讓測試人員了解到他們的價值
State Farm開設了一個佈告欄及網站，標示出測試與開發人員在開發初期發現到的缺陷及因為及時發現而省下的錢（超過上百萬美元）。將他們的工作重要性及對公司的影響彰顯出來有助於提振士氣，並且能鼓勵他們更有責任感。
別忘了負面測試 所謂負面測試，是用以避免像是使用者填表格時，沒有填滿必要欄位；或是輸入應用程式無法理解的資料時，可在螢幕上出現適當的錯誤訊息。
請開發人員儘量放手去做
在我們訪談中，不只一位CIO談到，開發與測試人員之間的摩擦，以及開發人員碰到品保人員時，會有多麼敏感，因為後者的工作績效，正是取決於他們測試開發人員成果時，從中抓出bug的能力。應用程式交給測試人員來挑毛病，可能會讓開發人員很不安。這也難怪，畢竟他們怕測試人員找出的問題，會對他們不利，或者因此讓他們受罰。因此在你希望開發人員，能以他們的作品自豪之時，也需讓他們了解，測試人員的角色就是要從他們的作品糾出錯誤，而他們這麼做，純粹是工作的需要，而非存心找碴。你還得跟他們保證，如果他們是因努力工作而犯錯，又能從錯誤中記取教訓，那這些錯誤就不會反映在績效考核的結果上。
給予開發與測試人員交叉訓練
要促進兩種角色的員工彼此了解，交叉訓練是個很好的辦法，也可藉此改善雙方的關係。Hartford Property & Casualty Company的Lamb指出，這種作法還可以提升應用的品質，因為雙方在做自己的工作時，也能從軟體開發生命周期的整體角度去著手。
在封閉環境下進行測試
不要讓開發人員進到你測試環境，因為他們一定會忍不住想修改他們所寫的程式碼。要是開發者在QA人員測試時進來攪局，一定要把他們做了哪些變更，以及無法充份測試的部份，都統統記錄下來。這個動作又被稱為程式碼控制（code control）
分析程式碼變更的影響，以確保測試及開發人員溝通順暢
國際軟體測試機構（International Institute for Software Testing）董事長Magdy Hanna指出，測試經理一定要定期與開發部門經理溝通，以便找出測試之後，開發人員又做了哪些變更，好重新進行測試，因為變更將影響整支應用程式。「分析變更影響，將可以大幅提升軟體可靠性。」他這麼表示。
所有開發人員變更或增加的程式碼，都要做測試案例（test cases）
有人稱它為程式碼涵蓋（code coverage）。程式碼涵蓋工具，是用來追蹤，對已測試過的程式碼，所做的新增或修改狀況，這樣你才能知道測試效果好不好。程式碼涵蓋，也能確保你的變更都經過測試，因為程式碼變更時，經常會導致bug的出現。在State Farm公司，開始採用程式碼涵蓋的方式前，大約只有34%的變更部份，會進行測試案例。而在做過程式碼涵蓋後，現在該公司測試案例涵蓋範圍，已經提昇到70%-90%的水準。
掃描程式碼找出已知問題
State Farm的Mike Fields表示，市面上有工具可以掃描程式原始碼，找出已知問題，並根據分析產生報表。這些工具會偵測與報告，某項動作總是造成記憶體漏失（memory leak）的狀況，或是把某個變項做特定的分派，並不是業界的最佳解決方式。Fields說，雖然這類工具可以用買的，不過State Farm卻覺得，市售工具功能不敷需求，因此該公司是採用自己開發的掃描工具。
辨認出資料規則（pattern）
State Farm利用柏瑞圖工具（pareto tool），從有問題的資料中找出規則樣式範例（pattern）。這個項目可幫助他們，找出軟體缺陷發生的原因，像是需求不夠準確，或是註解做得不夠….等等。
準備替代計劃
你的測試永遠都會有盲點。無論你再怎麼小心，測了又測，應用程式可能還是會出狀況，因此你最好有一套應變計畫，以便系統上線運作不如預期，或最壞的情況發生時，應該怎麼處理。Marshall Andrew應變計畫的思維是，一旦系統出現狀況時，要怎麼回覆到原來的狀態，以及Station Casinos的解決方案，對客戶可能造成的影響。
開發與測試人員間的恩怨情仇
Hartford's Property & Casualty Company科技基礎架構助理副總裁John Lamb，談到開發及測試人員之間，經常有不合的狀況發生。他說：「測試人員的工作績效，是取決於他們抓bug的能力；而開發人員則往往受到預算及時間限制的壓力，因此他們的工作目標，在某種程度上是衝突的。開發人員應該做基本測試動作，但有時QA測試人員會告訴他們：『如果你要測1到5，應該要連1到6也測試。這對開發人員人員而言，感覺起來就是在找他們的麻煩。』這種情形經常發生，很有意思的是，我有個兒子現在一家大公司工作，他是專案的首席開發人員。有一天他告訴我，他老闆老是讚美測試人員，而且依據他們抓錯的能力，來評估他們的績效。我兒子的想法是：『這不是打擊測試與開發人員的士氣嗎？』我告訴他，測試人員一定得用他們找出問題的能力，作為評估的標準，這是他們職責所在，而且並不致於打擊士氣。如果你在QA領域想偷懶，你就無法出頭天了。」Lamb說，如果開發及測試人員，不能相互尊重，也不坦白溝通，「專案想成功可說是遙遙無期。」