[上課心得] Odd-e實例化需求與自動化驗收測試

-
你有想過怎麼把業務需求轉成自動化驗收測試執行嗎?

你對產品的理解和其他團隊成員都相同嗎?


image

還沒有上這堂課前, 我不太清楚該如何設計自動化的驗收測試
驗收測試應該在軟體開發的哪個階段執行

這門課程帶給我的除了對自動化驗收測試架構有新的認識
還讓我了解能真正把業務需求轉為具體的測試案例是一件更重要的事情

關於需求這件事

今天如果你原來是RD或QA，讓你來把客戶的需求寫成文件
同樣地，如果你是BA或PM，讓你去看RD或QA寫的需求文件
你覺得團隊其他成員照你寫的做能看懂幾成?

通常都是宣傳猛如虎，溝通隨便唬

溝通需求的方式?

回想一下，大家平時在工作上是如何溝通需求的?
  1. 跟user面對面開會一邊寫文件, 有甚麼問題當場看直接溝通
  2. BA先寫好需求文件, 拉內部開發團隊人組一個work through meeting 討論
  3. RD開會時討論出一個方向以後, 就先做prototype給user看 然後再去更細部的討論
    開會完以後會有會議記錄讓user簽名畫押, 然後把這些需求寫成詳細文件 最後再把這本厚厚的需求規格給user簽名, 才下去做開發
  4. Product Manager把需求文件放在網頁上, 讓RD與QA在開發測試時做參考
但實際上發生Production issue的時候, 我們或許都遇過像這樣的場景...
image
如果你有把QA發的Bug做個統計會發現有不少的Bug都來自於需求溝通所造成的
有許多的重工、重作都來自於我們想的和客戶不同
開發團隊如何交付正確的軟體，基本上需要做好這兩件事
  • 確保建置正確的產品　(Build the right thing)
  • 用正確地方式建置產品 (Build it right)
image
有沒有一個方式能讓我們用一致的方式去溝通需求，又能夠自動頻繁的做驗證呢

有低, 介紹你好藥, 斯斯保肝 不含類固醇

什麼是實例化需求(Specification By Example)

實例化需求(SBE)是一種協作的軟體開發方式
使用具體的案例與自動化驗收測試來展示業務需求的一種模式
實例化需求能讓我們用以正確的方向建置產品 (Build the right product)

實例化需求對我們帶來的幫助

  1. 達成開發團隊內部對產品需求產生一致性的共識
  2. 減少溝通需求所花費的時間與成本
  3. 減少Production defect
  4. 能快速修改反映需求上的變化

實例化需求關鍵程序模式 Key Process Pattern

許多成功的團隊普遍會採用像這樣的關鍵模式(Key pattern)來執行SBE
這幫助他們了解每個流程中如何該建立產出物(artifact)和產生貢獻

image
  1. 從目標中獲取範圍
    團隊以客戶的業務目標開始，經由協作來界定可以達成的目標範圍
    產出: User story
  2. 協作制定需求規格
    團隊成員通過與客戶的溝通協作，制定需求規格
  3. 舉例說明
    團隊與客戶合作用舉例的方式描述預期功能的關鍵實例(Key example)
    產出: Gherkin語法的具體實例化案例
  4. 提煉需求規格
    團隊提煉實例，移除多餘的資訊，建立具體且精確的背景　　
    提煉好的實例(specification with example)可以當作交付的驗收標準
  5. 進行自動化驗證
    開發過程中，自動化驗收測試會多次驗證系統，以確保系統符合目標
  6. 頻繁的驗證
    頻繁的檢查讓團隊發現系統與規格之間的差異
  7. 演變為說明文件系統
    隨著專案的開發、團隊理解與市場業務變化，更新規格來反映這些改變
    演化成活的說明文件系統 (Living Documentation)
更進一步來看包含這些過程:
image

這門課程的第一天Joseph和柴叔帶我們演練怎麼將需求(user story)依照Gherkin語法寫成可執行的自動化測試案例

第二天我們用Cucumber實作練習將許多案例寫成自動化驗收測試腳本
時間很短，但收穫很豐富

學到的重要觀念

這門課程中, Joseph和柴叔帶給了我們許多實際上在團隊裡面運行SBE的建議作法
這些都是在書本或是網路上找不到的實際知識
  • 實例化需求的目的就是對關鍵需求達成共識
  • 盡量用具體的方式來描述需求，關鍵的訊息越具體越好
  • 關鍵的需求在用戶與團隊之間先達成共識，實現細節可以讓開發自行發揮
  • 但是對客戶來說，透過上線、發佈與刻意收集反饋 才能實際知道客戶真正的需求
  • 有很多bug是其實是沒搞清出需求所導致的 根本不是真正的bug
  • 把需求寫成實例化這件事的代價小，效果好
    相對自動化測試的實現時間長，難度高 並且不是甚麼都能自動化
  • 但長遠來說，SBE要有自動化測試才能達成快速且頻繁的驗證反饋
  • 能夠控制數據, 你的測試程式碼就會越簡單

課後心得

  • 沒有清楚的將需求轉為實例化案例, 達成共識。
    即使具備了自動化開發技術，不是在做正確的產品, 所花的功夫依舊是白搭
  • 知識的詛咒
當你對一件事情很了解，這種情況下人很容易用抽象的語言來表達他知道的東西 描述的人有很高的信心聽的人都能聽懂(70%) 但實際上聽的人可能只有30%不到真的了解
  • 要將模糊的需求寫成具體的自動化驗收案例不容易，需要多寫多練習
  • 重新接觸Calabash以後，我發現在安裝和使用上都比我想得更簡單方便。我該去學習一下這個工具了

Reference:

Comments

Post a Comment