3. 越早開始越好

(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. 只有自動化舊功能:一般來說舊功能是比較不會變動的,或者是變動的幅度有限。因此你若是只針對這些範圍的功能去做自動化,你就不會受到RDcode的影響,投資保酬率或是進度就會比較好。

d. 其實最後還是要回歸基本面:要僱用開發能力強的QA。有時候改的地方真的太多或是太大;或者就算不大,在時間的壓力下,開發能力沒有三兩下的QA是無法應付的。

創作者介紹
創作者 kojenchieh 的頭像
kojenchieh

David Ko的學習之旅

kojenchieh 發表在 痞客邦 留言(0) 人氣()