在敏捷開發環境中進行測試 (Testing in an agile environment)

測試的基本原理仍然適用於敏捷的世界，但是測試的目標可能會相當不同。

首先，必須清楚認知到測試是為了達成以下目標：

• 盡可能地打造最優質的系統
• 確定它能滿足客戶的需求
• 以大家都同意的、可負擔的成本完成系統的建造（成本包括金錢、商業環境變動，風險等）

 大家常認為測試的目標，就只是去驗證做出來的產品而已。您的測試應至少兼顧以下七個概念：

• 打造品質
• 優良品質人人有責
• 快速反饋
• 測試是產品的一項資產
• 更快速將產品放到正式環境
• 用明確、一致的原則進行測試
• 得出最佳解

打造品質

從一開始就盡力建立品質，並且在過程中進行測試。別到開發結束才來做，那就太慢了。

把使用者故事訂出驗收標準。可以在剛開始寫使用者故事的時候就訂，或者在開始進行開發時，以可接受性測試的方式進行。測試應該用來確認你已經知道和瞭解的部分是真的，使後續的階段不會有意外產生。

優良品質人人有責

服務的品質不是寫寫測試就能確保的。系統的品質，是由創造出系統的人來定義。

團隊中的成員應能辨識出系統中的品質問題。參與專案的每個人都應該採取行動，以增進系統品質和修復問題。

快速反饋

一個敏捷式專案的成功，有賴於不斷的快速反饋。不但要反饋，而且要快，意即可以真正敏捷迅速地進行專案，並且在需要改變時進行改變。

測試應該是要快速地給出和獲得有用的反饋。自動源碼測試技術有其重要性且可以一用，但別把此當成是最主要的測試手段。

測試是產品的一項資產

當建立一項測試時，把它變成一項標準，讓此測試在專案過程中可以多次進行。

要把測試做得正確，需要花費大量精力。所以別把它當成一個用完即丟的小練習題，以致於每個新版本或者新專案都要從頭開始建立一項測試。

請付出和撰寫產品程式碼相同的心力和精確程度，來編寫你的自動化測試。

更快速將產品放到正式環境

測試對於計劃是必要且有價值的，但程式碼上線後才進行測試的話，這些用在測試上的時間就是浪費的了。

透過測試去快速確認所有東西是否都如您預期，或是要修正。

並非在每個階段都要測得非常完整，但一定要跟目前階段相關。您的團隊必須對每個階段所必須進行的測試有哪些達成共識，而這些決定基於產品負責人的偏好順序，以及應用程式當中發生風險的可能性而定。

用明確、一致的原則進行測試

參與您項目的每個人都需要瞭解並同意：

• 測試方式
• 這些測試適用的情況
• 他們需要做些什麼

得出最佳解

如果測試做的好，將可以引領您走在最好的道路上。無論是在各式各樣的功能性和非功能性方面，測試都能提供許多價值，而且還能幫忙以下事情：

• 幫助做出艱難的決定
• 根據每個使用者故事的風險，指引開發的方向
• 根據系統的複雜性，幫助找出優先順序

測試的類型

在敏捷式開發專案中的測試，和一般專案中的測試最顯著的不同，就是測試將會以自動化測試為主。

這些測試會在持續性整合時被執行，也就是測試程式會成為您的源碼庫(Codebase)的一部分。每當您對原始碼作出變更，您的測試就會自動被執行。您馬上就會得到關於程式品質的反饋，如此也能幫助預防在後續的階段產生程式臭蟲（屆時要除去這些錯誤將會變得複雜、成本又高。）

原始碼測試

請閱讀測試原始碼指南。

探索性測試

「探索性測試」這個詞彙通常是指沒有被寫進腳本(Unscripted)的手動測試。測試員運用其知識、經驗，以及直覺，在軟體當中辨識問題所在。

非腳本和腳本測試之間的區別是，腳本測試只能測試一個事前決定的結果。探索性測試（非腳本測試），並不意味著不用為測試進行準備。

探索性測試：

• 總是事先計劃，包括了：
  • 您想要探索的特定面向
  • 為了執行測試所需的額外資料或必須建立的系統
• 用於找出並測試那些比較不顯眼的結果（自動化測試能夠避免臭蟲產生，而探索性測試能夠抓出臭蟲）
• 通常有時限（在一段固定時間內進行）
• 有一個特定的目的。例如「我將花費X小時探索系統的Y和Z方面（雖然我有可能轉而探索其他方面，而且會花上比預期或多或少的時間，我會運用我的判斷）」
• 不一定就不自動化。自動化技術可以用於資料的準備，或者獲取一系列的交易記錄（而不是只用來執行測試）

團隊中的品質分析師或測試者會負責執行這一類的測試。如果團隊僅由開發者所組成，那麼您將需要花一些時間與開發者一起進行測試，但請謹記於心：

• 由於開發者對已這些程式碼非常了解，有時對他們來說要以先前沒想到過的觀點來重新檢視系統相當困難
• 指派開發者用一整天時間去做探索式測試，讓他們進行幾次情境脈絡的切換（這是指CPU在工作和工作當中進行切換，並且不讓工作打架的方式），是一種理想的做法
• 最好讓他們探索系統中那些不是由他們所開發的部分

如果手動測試找出了缺陷，很重要的是一定要為此撰寫自動化測試，讓問題不再發生

請閱讀Cem Kaner談探索性測試

負載和性能測試

請閱讀負載和性能測試指南

滲透測試

請閱讀滲透測試指南

無障礙測試

請閱讀無障礙測試指南

群眾測試

群眾測試並不是叫一群人來做測試（這種叫外包測試 (outsource testing)）。這是找不同地方、進行不同工作的不同人。如果想要加快您的手動測試、增加測試的覆蓋範圍，這是一個好辦法。

外面有公司專門提供這種服務，但GDS是用以下方式在內部進行：

• 從組織各部門召集盡可能多的義工，請他們在某一天空出幾小時幫忙測試
• 關於需要測試項目，給他們一些引導
• 告訴他們去哪記錄程式臭蟲
• 有時候可以建立一個「排行榜」，列出測試了最多項目的名單，來激勵測試者

以下是一些GDS有效使用這些方法的實例：

• 在網站發佈之前，對於額外的裝置／瀏覽器支援程度的測試
• 仔細檢查GOV.UK的數百條內容，將其與DirectGov跟BusinessLink上面的舊資料相互比較

測測你的想法

別忘記囉，可別只測試產品本身而已，也測測你的想法吧。怎麼做的相關資訊請閱讀用戶研究 指南。

/making-software/testing-in-agile

譯者：
校稿：Richard
原始出處：https://www.gov.uk/service-manual/making-software/testing-in-agile