幾天前 Teddy 不小心誤闖了 Scrum Community in Taiwan Facebook 社團的某個討論，其中有一小段討論提到這個議題：在 sprint 中會不會經常無法完成測試的工作？這樣講其實不太精確，何謂『測試工作』？是指 programmers 所做的測試還是 QA team 所做的測試（路人甲內心獨白：我們沒有 QA team...XD）。亦或是兩者皆有？
今天就來談一下這個問題，這邊講的『測試工作』包含 programmer test 和 QA test，但是相信在台灣，有許多小型的團隊是沒有專屬的 QA team 一起配合，所以這個問題又可以區分為沒有專屬 QA team 與有專屬 QA team 來討論。
先談談前者，若是團隊沒有專屬的 QA，則可以由 Product Owner 兼做驗收（功能）測試的工作。理想上，這樣的團隊如果能達到 continuous delivery（自動且頻繁地產出可執行的軟體產品），則只要 developers 一完成某個 story 甚至是該 story 裡面可供測試的 task, Product Owner (或是其他 developer) 就可以立即對這個 task 作驗收測試。當某個 story 所有的 task 都完成之後，通常還會有一個單獨的 testing task 來對整個 story 做測試。
由於 developers 在開發的時候會撰寫 unit tests，而每個 story 所包含的 tasks 在完成之後也都會被測試，因此當整個 story 完成時，所需要的測試時間相對就比較短，而發生的問題也會比較少一點。在此情況下，很少會遇到『測試要等到下個 sprint 才能做完』的情況。但是有時候還是可能發生 story 完成之後 sprint 已經快結束了，所剩時間有限（例如，sprint 結束的那個禮拜的禮拜四下午快下班才完成），因此在 sprint demo 時該 story 就可能被測試的不是很完整。在這種情況下，可以選擇在 retrospective meeting 之後利用下班前的時間再補考 補測一下。若有發現 bug 則列入下一個 sprint 中優先修正。
如果團隊對類似 Robot Framework 這種自動化功能測試的工具熟悉的話，那麼就可以將一些原本由人工手動執行的功能測試，逐漸用自動化功能測試案例來取代。最後還要加上一條原則，就是『每次只要有人發現 bug，就一定要寫一個測試案例（單元測試，整合測試或是功能測試皆可）來確保相同的問題如果以後還繼續發生，可以被測試案例給找出』
最後，就是每天晚上在軟體所支援的平台上，自動將這些測試案例全部跑一遍，如果隔天發現有問題，則立刻釐清問題並加以排除。排除的方法有可能是測試案例寫錯（不穩或是因為待測程式與待測資料改變而導致測試案例的內容需要修改），測試環境有問題，或是待測程式有 bugs。
鄉民們可能會說，這樣光靠 Product Owner 來手動作驗收測試不夠啊。是啊，但是想一想，一個沒有 QA team 的團隊，能夠做到這樣，算是仁至義盡，老闆和客戶也該偷笑了。
***
如果團隊有專屬的 QA team，則測試的方式有兩種。
- 今日事，今日畢：在同一個 sprint 中，QA team 要把 developers 所完成的 stories 全部都測試過。
- 今日事，明日畢：QA team 測試 developers 上一個 sprint 所完成的 stories。
無論採用那一種方法，有兩件事情是很重要的。
- QA engineers (or testers) 要有能力設計測試案例（測試腳本）：這一點聽起來像是廢話，但是 Teddy 相信有很多 testers 是不會自己去設計測試案例的，只是依據 developers 所提供的測試項目去做測試，基本上算是『真人版的 Robot Framework』。要能夠設計案例，testers 一定要跟參與開發的活動，知道每一個 story 真正要完成哪些功能，這樣設計出的測試案例 coverage 才會比較足夠。
- 能夠自動化的測試盡量想辦法自動化：測試案例永遠都寫不完，也不嫌多。但是，如果這些測試案例都要由『真人』（手動）來完成，那麼完整測試一次的時間會被拖得很長，如此一來就無法搭配 developers 的進度（簡單講就是要能夠自動 regression testing）。至於哪些沒辦法自動化的測試案例，那就三不五時動動手測試一下吧。
***
友藏內心獨白：買翻譯機要真人發音，做測試則要假人測試（自動化測試）。
沒有留言:
張貼留言