David Ko的學習之旅

在敏捷開發方法大行其道時, 很多人在問測試要怎麼進行? 是否只要 TDD/BDD 就好? 傳統測試的做法還可以嗎? 我想很多人都有類似的疑問, 今天就讓我一一道來
 

 
 

    探索式測試 (Exploratory Testing) 是敏捷測試中一大技法. 可是在過於強調自動化的潮流下, 往往我們會忽略這個做法. 今天來給大家整理一些基本資料, 以方便大家學習.
 

我想大家都知道, 唯有給客戶想要的東西, 這樣你的產品才能大賣. 可是這樣的道理真的不容易做到.
那可以怎樣改進呢? 我想很多人一定問過這樣的問題. 並且最常見的反應, 是說自己根本沒有機會可以跟客戶接觸; 或者說即使跟 PM 講了, 他們也不會接受.
不過, 我想可以換個角度來思考一下, 為什麼大家不先從自己能夠掌握的地方開始練習呢? 如果你能夠讓你接觸的人滿意, 當日後有機會接觸到, 你所謂真的客戶時, 你才可能讓他們也滿意.

最近開始在研究實例化需求(http://www.amazon.com/Specification-Example-Successful-Deliver-Software/dp/1617290084), 開始帶領團隊看書和練習. 我們志不在自動化, 而是確認如何落實這樣的觀念到專案中, 了解要如何實際應用, 並且確保是有效果的.
昨天進行了一場需求工作坊, 我把一些事情記錄下, 以供後面持續改進.

讀書摘要: 敏捷測試的思考 (3)
Practices for Scaling Lean & Agile Development
Chapter 3 Testing
5. 避免將開發與測試分離
- 傳統測試的想法
(1) Coding是建設性, Testing是破壞性, 因此programmer不能進行測試
(2) 如果programmer測試自己的代碼, 那麼他們就會根據實作的情況, 改變測試的內容
(3) 當測試是由同一個開發的團隊來進行, 他們容易為了期限要到了, 而省略測試
- 因此在傳統測試中, 測試的獨立性是把測試和開發分離. 在agile中, 需要的是精神上的獨立, 而不一定非要由團隊中其他人員進行測試.
- 傳統把測試和開發分開, 讓開發人員和測試人員之間沒有共享的相同目標, 也導致他們不容易共享訊息
- 利用測試先行, 也就是在程式實現前先寫測試, 這樣測試就不會受到實作的影響, 因為這時候程式還沒產生. 這樣使得測試工作在精神上獨立, 可是卻不需要單獨的測試部門.

讀書摘要: 敏捷測試的思考 (2)
Practices for Scaling Lean & Agile Development
Chapter 3 Testing
3. 避免複雜的測試用語
- 通常測試的活動包含很多項目:
 單元測試, 功能測試, 壓力測試, 互通性測試, 負載測試, 安裝測試, 文件測試
 模擬測試, 系統測試, 穩定性測試, 相容性測試, 流量測試, 安全性測試, 探索性測試, 驗收測試
 整合測試, 回歸測試, 可靠性測試, 效能測試, 開發人員測試, 用戶驗收測試
- 複雜的術語本身無害. 但是它們經常導致人們只專注在自己的專業領域, 限制自己學習更多不同領域的東西, 且不小心還會落入局部最佳化的狀況

讀書摘要: 敏捷測試的思考 (1)
Practices for Scaling Lean & Agile Development
Chapter 3 Testing

資料來源: The Seven Deadly Sins of Agile Testing
http://properosolutions.com/2011/03/the-seven-deadly-sins-of-agile-testing/
 
 

甚麼是Acceptance Test-driven Development?
ACCEPTANCE TEST-DRIVEN DEVELOPMENTWITH ROBOT FRAMEWORK
by Craig Larman and Bas Vodde