問題7: 把需求和測試當成兩件事
若是把需求和測試當成兩件事, 我們很難知道事情是否做完, 或是是否做正確. 因此我們需要以下做法
(1) 分析師和測試人員需要變成好朋友
– 分析師要學習如何撰寫測試, 測試人員要學習如何向分析師般的思考
– 唯有分析師和測試人員密切合作, 才能發揮 1+1 > 2
(2) 建立可執行的規格
– 讓需求寫成測試個案的形式, 通過測試就是達到需求
– 若是能利用cucumber這類型的工具來表達需求, 那就更棒
(3) 利用範例來描述需求
– 不要只是規則和狀況, 若是以實際範例解說會更加清楚
(4) 採用 ATDD 和 BDD
(5) 使用 TDD 和 CI
問題6: 測試落後程式撰寫一個sprint
Scrum 規範在同一個 sprint 中, 每個功能要被撰寫, 並被測試通過, 這樣才能交付可出貨的產品. 可是事實上, 往往測試落後一個 sprint 才進行. 解法如下:
(1) 把 user story 切得更小
(2) 還有一些
– 在 DoD 中加入通過測試這個項目
– 讓 QA 在整個過程中加入討論
– 整個團隊都需要對品質負責
– RD 和 QA 更緊密合作
問題5: 不均衡的測試象限
Agile testing quadrants
定義了所要做的測試項目. 但是大部分的團隊, 只執行了其中某些項目而已. 建議作法:
– 自動化 acceptance test, 以有空來進行其他 quadrants 中的項目的測試
– 把 exploratory testing 加入到驗收測試中
– 在專案早期, 把某些測試 (performance, -ility) 外包出去給外面或是內部其他團隊來進行
問題4: 忽略失敗的測試
雖然某些團隊做了很多測試自動化, 可是當測試沒有通過時, 卻沒有去查為什麼失敗. 處理方式:
– 當測試不通過時, 停下手邊的事去查清楚為什麼
– 讓利害關係人也收到測試結果的通知
– 投資資源去建立更穩健的自動化測試
– 對於那些 clean check-in 的人要有適當的獎勵
問題3: 沒有實施 TDD 和 CI
– 團隊需要對 TDD 和 CI 有明確的承諾
– 對於 legacy 的部分要適度投資一些測試自動化
– 要有些 measurement, 來顯示 TDD 和 CI 的投資報酬率
– 對於要自動化的部分要列出其優先順序, 以最大化其投資報酬率
問題2: 獨立的 QA團隊
QA 常被視為是另一個團隊, 只有在專案後期才被邀請加入專案的進行. 其處理方式如下:
– QA 需要是團隊中的一部分
– QA 需要和 RD 做在一起
– product backlog 中需要包含 QA 的項目和工作
問題1: WaterScrumming
有些團隊雖然號稱是 scrum, 但是 sprint 卻看起來像下面這樣
sprint 1: analysis
sprint 2: analysis
sprint 3: coding
sprint 4: coding
sprint 5: coding
sprint 6: testing
這只是變相的waterfall. 可以採取的方法有
– 讓團隊學習更深入的 agile practice 的知識
– 利用 pilot project 來讓你知道 agile 是怎麼一回事
發表迴響