放下心中舉起的中指

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 框架之後在來考慮自動化測試，以免一次導入太多新的東西團隊成員無法吸收。

***

友藏內心獨白：放下中指，立地改善。