在敏捷開發方法大行其道時, 很多人在問測試要怎麼進行? 是否只要 TDD/BDD 就好? 傳統測試的做法還可以嗎? 我想很多人都有類似的疑問, 今天就讓我一一道來
首先, 傳統測試是根據傳統 waterfall 開發方法建立出來的. 他假設前面需求已確定, 所有功能已開發完畢, 所以接下來就是用力把這些功能給測好. 如果品質有問題, 就不能讓它通過.
但是在敏捷開發中, 是以迭代的方式進行, 每次開發部分的功能, 然後交付, 看看反應如何再進行調整. 之前傳統測試的假設: 都開發完, 最後把關 等等, 這些都已經不成立了. 因此, 在測試方面的做法不得不改, 需要針對敏捷開發流程的特性做出調整.
那敏捷開發流程的特性有哪些影響測試呢?
(1) 迭代進行
因此短時間要把新功能給測試完, 並且也要確保不會影響舊功能
(2) 強調協作
敏捷團隊希望大家可以略懂略懂, 或者沒有強調角色別, 因此測試的知識人人都要會.
(3) 及早確認
因為迭代時間不長, 有事情就要立即確認, 尤其需求的部分, 沒有太多分析時間. 如果最後才抓到很多問題, 不是代表你行, 反而讓大家最後都交不出東西來.
(4) 功能需要拆解
迭代時間有限, 需要把要做的事情拆解成小事情, 把有價值的先做, 並且根據做的結果進行調整. 有些系統性的測試, 並不能最後才一口氣做一個大的測試.
為了要能敏捷開發中, 把測試的工作給做好, 你需要做得夠快, 因此自動化的幫忙, 很佔很重要的地方.
但是自動化不是只做單元測試, TDD, 或是 BDD. 整條開發線上的事情, 能夠自動化的都該自動化. 像是測試環境的部署和建置, 系統測試 (壓力測試, 效能測試, 安全測試等等), 回歸測試, 程式部署和監控都要自動化.
這裡 RD 常常誤解只要 單元測試有自動化就夠了, 其他部分的測試可以不要做. 只靠這些測試是抓不到所有類型的問題.
另外, RD 也有很致命的缺點, 大多他們沒有測試的相關知識, 並且也不太想學, 出現的測試大多是 happy path, 其他部分不太管.
至於測試人員, 雖然有測試的相關知識, 但是對於自動化方面大多不太行. 畢竟在短週期的迭代中, 沒有自動化測試的保護網, 要快點做完新功能的測試, 又要顧好舊功能, 最後只會讓 QA 放盡力氣.
另外, QA 的心態也需要轉換, 不該是已把關者自居, 因為最後階段找到問題不過關, 那只是大家一起死. 必須要在早期就提出建議, 提醒 RD 要注意什麼, 讓 RD 把這些考慮進去. win-win 才是致勝之道.
所以, 在談 agile testing 時, 需要有 開發 和 測試 兩邊的知識和技能, 又要能從開發早期照顧到晚期, 不能只看單元測試還要照顧到系統測試. 如果你只是從傳統開發人員或是測試人員的角度, 可能就會像瞎子摸象, 都是只看到一部分. 並且也不太懂其他. 因此, 在談敏捷測試這個主題, 往往是需要 RD和 QA 都來聽, 一起討論要如何因應, 這樣才會有好的成果.
全站熱搜
留言列表
