[30天快速上手TDD][Day 20]ATDD - User Requirement

[30天快速上手TDD][Day 20]ATDD - User Requirement

前言

TDD 系列文章到這邊,只是獨立介紹了測試與重構,接下來要介紹的部分,則是筆者認為 TDD 整個流程中,影響成敗的一環,也就是從 user requirement break down 到 acceptance testing 。

TDD 可能可以幫助開發人員產出 high quality 的程式碼、物件、甚至模組,這些程式碼有高可維護性、可擴充的彈性,但使用者對程式碼的開發流程、工具、方法並沒有興趣,使用者只想滿足他們的需求,透過我們的系統提高生產力、解決問題,或是創造更多的利潤。

這也是這整個系列文章的主旨:一切都是為了滿足使用者需求而存在。

這篇文章會先從使用者需求管理的方式開始說明,也將常見的幾種方式,如 user story, use case ,以及功能清單三種,簡短地做個比較。

瞭解 user requirement 之後,後面我們才能開始進行 ATDD(Acceptance Test-Driven Development),因為 test cases 不會憑空產生。

註:本系列文章,會以 user story 為主軸,因為在 Scrum 中,透過 user story 來管理使用者需求,是一種輕量級、又相當具備彈性的方式。

 

介紹

如前言所說,接下來要介紹的部分,是筆者認為TDD整個流程中,影響成敗的一環,也就是從 user requirement break down 到 acceptance testing 。這也是一般文章或書籍中,比較少提及的部分,然而也是筆者認為大家對 TDD 在實務上應用,最缺少的一環。

正因為少了這一環, TDD 的起手式,會導致大家認為:TDD 不就只是個先寫測試的開發方式罷了。

當把 user requirement ,串到 ATDD ,輔以 BDD ,搭配 TDD ,一路打通任督二脈之後,在 Scrum 的流程中, Agile 的精神中, XP 的基礎建設上,整個開發流程,每個階段,每個角色的串接順暢,資訊基底一致,筆者才體會到了 TDD 的美妙之處。

也希望接下來幾篇文章,不會讓讀者們失望。

 

V-Model

一般軟體開發流程中,常見的 V-Model 如下圖所示:

(出處: http://www.testingexcellence.com/v-model/)

V-Model中,可以看到基本上開發流程的幾個階段就是:

  1. 使用者需求蒐集與分析 ( RA )
  2. 系統分析 ( SA )
  3. 架構/系統設計 ( SD )
  4. 程式開發 ( PG )

接著每一個階段有對應的測試來進行 verify 與確認執行無誤。

上面這張V-Model的圖,在後面幾篇文章中,會有不同的進化。

從 V-Model 中也可以看到,在軟體開發流程中,第一步基本上就是蒐集與分析使用者需求,而驗證系統是否符合使用者需求,則是透過 User Acceptance Testing 。這也是為什麼,筆者一直強調使用者需求管理與驗收測試,在 TDD 中這麼重要的原因。

因為:系統的存在目的,是為了滿足使用者需求,而不是給開發人員寫爽的。

因此在講 ATDD ,介紹 acceptance testing 之前,筆者想先介紹一下 user requirement 管理(或是稱為「定義」)的方式。

 

User Requirement

在需求蒐集的過程中,我們需要透過一種方式,將使用者的需求以某種方式紀錄或定義,其目的如下所示:

  1. 用來供整個團隊與使用者確認,是否這些需求滿足之後,這就是他們要的系統。(參與的人員,可能包括了使用者、 Product Owner 、需求分析師、系統分析師、開發人員、測試人員)
  2. 供分析人員、測試人員、開發人員可以繼續往下進行系統開發的共同基底資訊。
  3. 用來檢視目前完成進度與驗收範圍。

這邊則針對 user story , use case 與一般常見的功能清單來進行說明。

 

User Story

使用者故事(User Story)是一種輕量級且相當靈活的使用者需求管理方式。

在系統開發之前,整個團隊都應該思考預期的系統行為,是否能夠滿足使用者的需求,這就是 user story 可以幫助我們的地方。

透過相當簡單好懂的方式,用大家都懂的語言,記錄下來使用者的需求。(大家都喜歡聽故事,不是嗎?)

這邊舉出wiki上的幾種 user story 格式,供大家參考一下:(來源

  1. 最原始的範本:點出role, goal跟benefit,格式如下:
    "As a <role>, I want <goal/desire> so that <benefit>"
  2. Mike Cohn 覺得上面的 so that ...不一定需要存在,但重點是 goal 一定要出來,格式如下:
    "As a <role>, I want <goal/desire>"
  3. Chris Matts 覺得,系統開發的重點在於可以給使用者帶來什麼價值,所以將 benefit 拉到最前面,格式如下:
    "In order to <receive benefit> as a <role>, I want <goal/desire>"
  4. 5 個 W 的格式,也就是人事時地物,格式如下:
    "As <who> <when> <where>, I <what> because <why>."

筆者自己認為 1, 2, 3 在使用上都挺 OK , 5 個 W 的格式則是太冗長。

例子如下圖所示:

user story sample

User story 的撰寫重點在於,用最簡單的方式,讓大家都可以瞭解這個需求是什麼。通常會 focus 在 What ,而不是 How 。一旦 user story 關注地太詳細,可能會導致開發流程中無法因應需求的變化。也額外的花費了太多的成本在於可能會一直變動、重工的部分。

筆者自己習慣的方式:

  1. 簡單的點出,這個需求的目的,由誰使用,需要什麼樣的功能。
  2. 如果 user story 的描述有 10 句話,拿掉其中 3 句話,仍能清楚表達需求,能瞭解目的、功能、誰,那就把這些多餘的話拿掉。
  3. 確定使用者看的懂、測試人員看的懂、開發人員看的懂,可以用最簡單的資訊,來當作彼此之間溝通的基底,用最快的速度完成共識,或是在需求變更時,用最快的速度、最小的成本推翻它 (笑)

User story 因為簡短,所以蠻多團隊會準備一些小卡: user story card ,將 user story 寫在上面,這樣的方式有幾個好處:

  1. 篇幅有限,可以限制廢話太多。
  2. 實際物體形式存在,讓大家更有參與感與透明感。搭配白板,也很方便可以呈現狀態的轉移。
  3. 可在上面標記 priority 。
  4. 可在上面標記目前負責人員。

使用 user story 時,也有個 3C原則 可以參考一下:

  1. Card
  2. Conversation
  3. Confirmation

簡單的說, user story 記錄在 Card 上面,可以拿來當作溝通的基底,最後 user story 要搭配對應的 acceptance test cases ,才能說明這個 user story ,也就是這個不包含太多細節的使用者需求,該怎麼確認完成( done )。

User story 切記不要寫太長,把步驟或細節都列上去,只會失去其最主要的意義與目的,如下圖所示 (from wiki):

  1. 簡短版
    簡短版
  2. 冗長版
    冗長版

讀者覺得上面兩個例子,哪一個好懂呢?哪一個有彈性呢?

想瞭解更多 user story 的眉角,建議大家可以參考 Mike Cohn 的 User Stories Applied ,(書上寫得相當完整,但許多都是實務上眉角的探討,並不適合當入門書)這邊因為篇幅限制,就不講太細太深,而是透過 user story 來當作 ATDD 的入口點。

 

Use Case

有透過 UML 來進行 SA/SD 的團隊(尤其是使用 MDA 的團隊),肯定對 Use Case 不會陌生。

Use Case 基本上分為兩段,一個是 Use Case Diagram ,如下圖所示:

Use Case Diagram

透過連使用者都看的懂的圖示,來說明下列的元素:

  1. 系統邊界。
  2. 參與角色。
  3. 使用案例。

夠抽象,就會穩定。

然而, Use Case 有時還會搭配 Use Case Description/Use Case Specification ,其中包含了 pre-condition 與 post-condition ,如同上圖的註解所簡單點出的部分。也可以參考一下這篇文章的簡介:[系統開發生命週期]Use Case Diagram補完

實際的 Use Case Description/Use Case Specification 其實要包含的東西相當多,讀者可以參考 wiki 上的說明:用例模版

Use Case Diagram 筆者也會使用,但使用的時機通常是拿來當作 SD 的開頭,而不是拿來當使用者需求管理的目的。例如:將 user story 透過一張 use case diagram 來圖示系統邊界、角色以及功能,三者之間的關係。

 

功能清單

這個在有導入 CMMI 的公司中,絕對是相當常見的東西,格式不一,但基本上就是長的像下圖所示:

功能清單

格式不一,目的就是需求管理,驗收清單。記錄著將使用者抽象、漫無邊際的需求,轉化成一支一支的功能清單,並且針對該功能進行簡單的描述,可能還會延伸出拿來派工( task arrangement ),即可看出由誰負責開發、測試、驗收等等資訊。

功能清單主要拿來做需求管理,在瀑布式開發方式與 CMMI 所重視的精神中,需求是需要追蹤以及妥善的管理,這都是對的,但是很容易就變成:需求需要在一開始就明確定義清楚,才能往分析階段前進,全部分析完成,才能往開發階段前進。

每一次的需求異動,都是一整個流程階段狀態的改變,也就是重工的範圍是會影響整個團隊中不同角色,甚至把開發階段回推至先前的狀態。這也容易導致階段、角色之間的對立,導致開發團隊並非一整個團隊,並非全力的為了滿足使用者需求而開發,而是責任歸屬、互推皮球,食物鏈式的往下壓榨。

這些,在 Agile/CMMI 的比較或 Agile的宗旨 ,如下圖所示,已經講得很清楚了,筆者就不在這著墨太多。

agile

 

三種方式簡單的歸納與比較

  1. User story :
    建立的成本最低,著墨的資訊也幾乎是最少,主要拿來溝通與管理使用者需求。需搭配 acceptance test cases 來確定如何可以認定為 done
  2. Use case diagram 搭配 use case description :
    一張圖可以快速的表象出人事物的關係,但只有圖容易太抽象,加上 description 則太冗重。建議可以選擇性的加入 pre-condition 與 post-condition 。好處當然是針對某一個使用案例,可以詳細的描述相關的步驟,但寫越多,需求異動的成本就越高。(後面文章有機會的話,會提到 pre-condition 與 post-condition ,可以對開發、測試上有什麼幫助)
  3. Function list :
    傳統的開發方式,學習成本較低,就只是一種文書整理的方式。可讀性較差,只能拿來當作驗收、請款、派工、需求異動管理的一份文件,對系統從需求要繼續往下延伸至分析、設計、開發的幫助最低。

 

小結

在 TDD 的流程中,講究的是小步前進,快速回饋,擁抱變化,重視溝通,滿足需求。所以基本上建議搭配 Scrum 的流程、 Agile 的精神、 Extreme Programming 的基礎建設

User story 在這三者中,最適合拿來當 TDD 的 user requirement 文件,因為建立容易、好懂、成本低,且可以表達使用者需求,搭配 acceptance test cases 來輔助後面的 ATDD 、 BDD ,進而進入開發人員最擅長的 TDD 循環。

所以,這系列文章,將會以 user story 為例子,說明完整的 TDD 開發流程。

試著擁抱變化,需求變更是系統進化的原動力,科技始終來自於人性。嚴禁需求異動,最終只會做出一個開發團隊自爽的產品,而不是滿足使用者需求的產品。

 

補充

補充一下一些 term 的全名:

  1. TDD: Test-Driven Development
  2. ATDD: Acceptance Test-Driven Development
  3. XP: Extreme Programming

 

參考資料

  1. Test Driven - Practical TDD and Acceptance TDD for Java Developer
  2. wiki

對敏捷開發有興趣的朋友,可以參考我的粉絲專頁:91敏捷開發之路

對 TDD 課程有興趣的朋友,課程內容、大綱與學員心得,可以參考 skilltree 的公開課程:自動測試與 TDD 實務開發

若需要聯絡我,可以透過粉絲專頁私訊或是側欄的關於我。