(1) 儘早和高層取得對測試自動化的共識
測試自動化有不少好處，但是它不是萬靈丹，它有它極限以及所要付出的代價。因此要及早和高層取得共識，讓他們知道什麼是測試自動化可以做到的，以及我們可以做到多少，並且要花多少effort。之後他們才不會有過度的期待，你也會較容易得到適當的支援，讓雙方能夠達到雙贏的結果。
(2) 及早和RD討論以增加可測試性(testability)
測試程式的撰寫是否可以有效率，有一部分是決定於受測程式的可測試性(testability)高不高。所謂可測試性是指什麼呢，就是指你對受測程式的可控制性，即你可以用哪些方法來控制受測程式的運作，方法越多或是越容易實作就代表可測試性越高。
有哪些控制的方法呢？有些像是增加一些額外的API；有些是在debug log中加入一些特別的output；有些是在UI上顯示一些訊息；有些是產生一些訊息在event viewer中。
如果RD一開始在設計時便成把這些機制加入到架構中，自然之後要驗證結果或是驅動測試時，才不會加上一堆奇奇怪怪的workaround作法。不但增加測試盛開發時間，也讓測試自動化的效果大打折扣。
當然啦，增加這些機制不是免費的午餐，主管也需要有認知，他必須要安排時間給這些工作項目。此外若是RD也有撰寫unit testing的習慣，這些工作就不一定是額外的花費。可能為了驗證unit testing的結果，RD也需要安排時間做這些事。
(3) 測試自動化最好能在RD開發完畢時就準備好
測試自動化的效果要彰顯，最好就讓測試程式能儘早開始執行。所以最佳的時間是在RD一寫完程式後，測試程式就能開始執行。但是，就像大多人知道一樣，程式不到最後關頭，通常決不輕言固定下來。有時可能是因為需求變動，有時是RD求好心切要做refactoring，理由是族繁不及備載。你可以有以下幾種做法來緩和這種狀況︰
a.盡量在RD開發完畢時，把所有測試程式在同一時間完成，讓你之後只剩下因應變動部分來修改你的程式。
b. 回到我之前講的，測試程式架構設計很重要。先和RD談過那些部分容易變動，再加上你的經驗，你可以在這些地方保留一些架構上的彈性。
c. 只有自動化舊功能：一般來說舊功能是比較不會變動的，或者是變動的幅度有限。因此你若是只針對這些範圍的功能去做自動化，你就不會受到RD改code的影響，投資保酬率或是進度就會比較好。
d. 其實最後還是要回歸基本面：要僱用開發能力強的QA。有時候改的地方真的太多或是太大；或者就算不大，在時間的壓力下，開發能力沒有三兩下的QA是無法應付的。
留言列表
