自動化UAT的一些體悟

自動化UAT的一些體悟


由於自動化UAT對scrum team來說是一個全新的技術, 所以在過程中往往會有很多天馬行空的測試方法, 這篇文章就以我目前運作一段時間以及跟組員們討論如何測試所理出一點心得.

所謂UAT(User acceptance testing, http://en.wikipedia.org/wiki/Acceptance_testing#User_acceptance_testing), 就是對一個solution依照user提出的requirement(或是我們的story中的how to test)驗證solution是否正常.

所以這邊我先點出一個重點, UAT測試的是一個solution, 以我們做監控軟體而言, 測試最大的涵蓋範圍就有, UI, functional plugin, Client/Server framework, recording server….所以他是一個整合性測試, 千萬不要覺得UAT只是拿來測試UI而已.

會有這個體悟是因為有天member在跟我討論如何驗證UI上顯示搜尋警報結果的功能. 這功能包括從server搜尋符合條件的警報, 回傳到client處理並建立model, 最後UI透過grouping的規則呈現這個model的內容.

問題就出在如何產生驗證資料, member認為應該是另外寫一段code從client的model拿到資料並根據grouping的規則, 再去跟UI呈現的內容作比對. 單就這方法而言如果只是測試UI的功能正不正常或許是ok的.  但這有幾個問題:
  1. 那誰要去驗證你寫出來的驗證程式正不正確.
  2. 就是我說的這個測試只能針對UI, 而不能是對整個solution做測試, 因為沒有測到client拿到sever資料以及組完model時的正確性.
  3. 想看看最前線寫test case的人員是DQA(或是PO跟user討論), 我想他們百分之百不會想到要用程式去產生一份驗證資料出來. 對DQA而言, 他們一定會先定義好測試條件跟環境, 然後針對各種條件就先把驗證資料蒐集好了, 這樣測試時才可以拿來跟solution得到的結果比對.

到這邊我要提出另一個重點, 就是測試資料跟測試環境的重要性, 這裡我有個慘痛的經驗, 就是我們的第一個自動化UAT的測試資料是用程式碼自動產生的, 也就是在test case要跑之前就先隨機產生測試資料, 我想就是這個錯誤導致member在驗證test case遭遇很多麻煩. 由於測試資料的不確定性, 導致test case每次測試時的驗證資料都不會是相同的.

測試資料環境的不確定性還會導致一個問題, 當發生test case不過的情況時, 你變成要去查到底是新增的程式碼發生問題, 還是測試資料或環境不合乎這個test case而造成的問題.
針對這問題, 後來我們就開始著手測試環境的建置, 針對每一個test case都應該要有他們測試環境跟驗證資料. 我相信要做到自動化UAT這個測試環境一定要花很多心力去建置. 但總比用程式去自動建置來的好太多了, 光想到當初開發跟maintain那些程式碼就讓我一度懷疑自動化UAT的好處到底在哪裡.

總結一下, 自動化UAT我認為就是把驗證test case的過程做自動化而已, 所以一個test case必須要先定義好以下幾點:
  1. 測試環境跟測試參數
  2. 測試步驟
  3. 驗證的資料
相信只要有以上的資料要做自動化UAT一定不是問題,歡迎大家一起來討論UAT。

0 comments