GDS Digital Service Manual 中文翻譯網站 (beta)
by HPX-GOV 英國政府數位服務研究小組 GDS Study Group
Home » 英國政府數位服務設計手冊 » 敏捷方法 (Agile) » 在敏捷開發環境中進行測試 (Testing in an agile environment)

在敏捷開發環境中進行測試 (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

請留言

你的email信箱不會被發布出來. Required fields are marked *

*