如何有效開立test case: feature-driven v.s purpose-driven－David Ko的學習之旅

如何有效開立test case: feature-driven v.s purpose-driven

通常我們開立test cases時, 都是以feature為導向, 來分配工作. 例如QA 甲測試 feature 1, QA 乙測試 feature 2. 然後可能給1~2週讓他們開立test cases, 之後再進行test case review. 可是這樣做我們遇到了一些問題

1. 大家都只會開functional的test cases
2. 太慢才能給feedback, 因為要等test case全部開完才能給feedback
3. TC 太多, 大家沒有空仔細去看完. 因為1~2週開完的test case量實在不少

因此我們team想出一個作法, 以purpose為導向來開立test case

(1) 先找出你覺得有哪些purpose的test case要開
build validation test
error force test
bounary test
scenario test
interaction between features
acceptance test
pseudo testing
security test
L10N test
performance test
.....

(2) 然後要求QA針對每個purpose 開立所負責feature的test case. 一次只對一個purpose來開立test case

2-1. original
feature 1
   purpose A
   purpose B
   purpose C
feature 2
   purpose A
   purpose B
   purpose C
feature 3
feature 4

2-2. new
purpose A
   feature 1
   feature 2
   feature 3
   feature 4
purpose B
   feature 1
   feature 2
   feature 3
   feature 4
purpose C
   feature 1
   feature 2
   feature 3
   feature 4

這樣的好處是
(1) 因為每個pupose的test cases不多, 所以要review比較可以看完
(2) 因為每個pupose的test cases不多,要花的開立時間也相對較少, 可以較快給feedback
(3) 可以確保各類的purpose都會有相關及適當的test cases, 不會只有functional而已
(4) 有機會藉由review或討論來更了解受測系統, 讓下次可以開的更好
(5) 不會只有一次開test case 的機會, 因為每次purpose都是一個新的機會

呵,呵, .... 這樣做會有比較agile嗎?