l

2010年4月15日 星期四

放下心中舉起的中指

04/14 22:48~  04/15 00:20

對於 PM 或是 project leader 而言,讓人最沮喪的事情,莫過於團隊成員告訴你程式都寫好了,但是你稍微使用一下卻發有問題。遇到這樣的情況,典型的心情的轉折為:『沮喪』--> 『生氣』-->『想罵三字經』。

無論最後那句 XXX 有沒有說出口,此時的心情是十分低落的。心中不自覺的響起許多怪東怪西的聲音:
  • 這些該死的刁民 (programmers),程式寫好都不測試的啊!
  • 這麼簡單的問題也要我來告訴你 (programmers) ?你不是『應該』要自己想到的嗎?
  • 真是太欠罵了,這個問題都發生過幾次了...
  • 這就是自己帶領的團隊嗎?是不是自己的領導太失敗了...

***

假設鄉民們的團隊採用 Scrum 方法,但是團隊中並沒有專門的人來負責驗收測試。為了確保每個 sprint 結束時所完成的系統品質不至於太差,可以採用在每個 story 裡面都加了一個 testing task 的方法 (這個 testing task 是做 functional testing,unit testing 已經包含在 programmers 開發功能之中),以確保 story (需求) 從『未完成』變成『完成』之前,會被團隊成員測試過。通常這樣的 testing task 會找非開發該 task 的團隊成員來領取,以避免測試自己測試自己所開發的功能(因為『自己寫,自己測』通常更找不到問題)。很多時候團隊成員在認領這些功能測試工作時,經常會發現,許多 有一些宣稱已經做完的 tasks,其實還是存在著 bugs。看到這邊,也許鄉民們或說:『程式有 bugs 是很正常的啊』。的確,之前 Teddy 也是這樣想,但最近看了 Lean 與 Toyota Production System (TPS) 的書之後,提高了 Teddy 對於『品質』以及『減少浪費』的意識 (測試找出 bugs,修改 bugs,再次測試,這些都是額外的浪費),因此越發覺的應該要重視這個問題。

Bugs 可以簡單的分成兩大類:

  • 情有可原的 bugs:雖然 programmers 有撰寫單元測試程式,但是 client 卻用某種『預料之外』的方式來呼叫自己的程式。這種情況勉強算是『情有可原』。
  • 不可原諒的 bugs:此類 bugs 又可細分為兩種
    • 偷懶:有時候 programmers 偷懶,只寫最簡單的單元測試。在正常的操作之下,只要步驟或是輸入資料稍微複雜一點點,就會出錯。
    • 自作主張:Programmers 在寫程式的時候,對需求不是很清楚(尤其是使用者介面的設計與操作方法),但又不肯問就坐在他旁邊的 product owner,而依照自己的想法把功能做完(通常都是過度簡化)。雖然完成的功能本身可能沒什麼錯誤,但是這樣的功能並不完全符合 product owner 所需要的需求。
當遇到『不可原諒的 bugs』時,相信每個負責測試的人員在心中會很想罵 XXX。但是,生氣,除了讓自己的血壓上升以外,並不能解決問題。此外,要求開發人員寫出零錯誤的程式實務上的確是非常不容易的(Teddy 自己也寫不出零錯誤的程式啊),因此也沒立場要求其他人不准犯錯。在 Scrum 中,可以選擇在 retrospective meeting 時把個問題提出來討論,在看看要如何改善。假設『不可原諒的 bugs』發生的原因為:

  • 資料庫問題:因為有一些和資料庫有關的程式,在測試的時候需要在資料庫中設定測試資料,而準備這些資料和執行這些測試程式都很花時間。因此,有時候就偷懶沒測。(這樣的理由聽起來雖然有點牽強,不過總是反映出和資料庫有關的測試案例不容易撰寫這個問題)
  • 開發人員自作主張(通常發生在使用者介面)的問題:開發人員經常是用最容易施工的方式來設計,沒有特別思考到是否容易使用或是一致性的問題,也沒有將設計好的雛型先請 product owner 看一下。

針對這兩個原因,可能會有以下的改善方案。
  1. 在下個 sprint 規劃一個 technical story,設計一組產生資料庫測試資料的公用程式,以簡化測試案例的撰寫。
  2. 著手整理 UI checklist 與 UI patterns,降低使用者介面不一致與不方便使用的問題。
  3. 對於全新開發的功能,一律增加一個撰寫 acceptance test cases 的 task,以減少由於對於需求細節不清楚造成自作主張的問題。
  4. 對於所有發現的 bug,一律要先撰寫一個自動化的 unit test 來重新產生該 bug。
當然還可以列出更多的作法,但是由於每個 sprint 的週期通常很短(2-4 週),因此列太多也不太可能一次改善完畢。逐步實施這四點改善方案,觀察一陣子之後再依據實際實施與改善情況來決定後續的改善方法。

***
QA 時間

鄉民甲:UI checklist 與 UI patterns 不是早就應該整理了,為什麼要等到問題發生了才整理?

Teddy:在系統開發之初,通常團隊並不確定這個系統會長成什麼樣子,因此可能無法對於 UI 做很多的 up-front design(事前設計)。隨著系統功能越來越多,product owner 在操作過系統之後才慢慢有一些具體的建議。因此,依照 agile 精神此時整理 UI checklist & patterns 應該算是合理的作法。


鄉民乙:『對於所有發現的 bug,一律撰寫一個自動化的 unit test 來重新產生該 bug』這個作法不是 agile methods 的基本要求嗎?為什麼不在專案一開始就實施呢?

Teddy:專案一開始的時候團隊可能還不熟悉自動化測試,為了讓團隊成員先熟悉 Scrum 框架,所以 Scrum Master 可能會把導入自動化測試這件事排在稍晚的 sprint 中在開始實施,等團隊熟悉 Scrum 框架之後在來考慮自動化測試,以免一次導入太多新的東西團隊成員無法吸收。

***
友藏內心獨白:放下中指,立地改善。

1 則留言:

  1. 請教一下,你們在進行與資料庫的測試時,所撰寫的 test 是真的去和資料庫連線呢 (當然要先塞測試資料進去資料庫), 還是你們用 mock / stub 的方式撰寫這一部份?

    回覆刪除