你的專案品質到底在哪裡？

你的專案品質到底在哪裡？

這篇文章的標題大概會是許多人心中永遠的痛。老實說，筆者瞭解至今仍然有許多公司直接就把客戶當作自己的測試人員，而且是沒有薪水的那種，某種程度來說也算是很有經濟效益了。

發生這樣的情形，相信即便是專案經理自己本身也是並不樂見的。不過筆者明白也明白在專案開發上有許多問題往往是現實環境造成，所以這篇文章也不想討論應該怎麼或者不應該怎樣的議題，那些就留給老天爺來決定好了。

那麼這篇文章究竟想說些什麼呢？筆者在假設大家是有在進行基本的測試工作基礎下，來與大家探討一下，測試這件工作究竟有沒有想像中那麼單純，而專案經理除了叫測試人員努力測試之外，其實可以藉由測試這件工作來更瞭解自己的專案開發團隊的運作情形。

測試不只是測試

這句話要怎麼說呢？

測試簡單來分的話大概可以分為三種，單元測試、元件整合測試以及情境測試。單純就測試本身來說，每種測試都有不同的目的與效果，分層把關，以便讓程式的BUG發生率控制在最小的範圍內。

單元測試是驗證程式中的每個片段（通常是以函式為單位）是否能夠正確運作，這個工作最有效率的話大概是程式開發人員自己擔任，為自己寫的函式撰寫測試程式，如果專案有要求進行單元測試的話，這個動作應該是要在程式交付前完成的。筆者知道目前有些工具是可以自動產生測試程式的，如果可以善用這些工具的話，對於測試的工作是即有幫助的。

元件整合測試則是在程式中整合進其他元件時進行的測試，需要確認每個元件是否都能正常的提供他們的服務，介面的銜接是否順暢，最後產生的結果是否都能通過。同樣的，當程式開發工作有加入新的元件時，程式設計師最好能夠在交付前就完成元件的整合測試。

情境測試則是驗證程式究竟是否能夠符合客戶的需要，產生客戶的價值，是程式是否滿足需求的最後一道關卡。以現實狀況來看，一般開發公司如果有測試人員的話，多半就是擔任情境測試的人員，只是情境測試往往還是發生了應該要在單元測試與元件整合測試時就該要發現的問題，導致專案的進度與品質難以掌控。

其實測試是一項很耗費成本的工作，對於人員的工作來說也是極大的負擔，因此，最理想的方式就是在不耽誤太多開發人員的時間，又能完成測試。能夠滿足這樣的條件即是所謂的自動化測試，現在已經有工具能夠符合這樣需求，也能在工作人員下班後進行自動化測試，一早來即可瞭解專案的測試結果。

品質指標

當看到這個標題時，筆者知道大部分人心裡一定會這樣想：「拜託，誰不知道測試就是專案的品質指標，這還用你講。」

當然，我們都明白測試就是為了專案的品質把關，問題是，有多少人懂得從測試的結果中瞭解專案的品質究竟落在什麼地方，如果好，那是多好，如果不好，又有多差呢？身為一個專案經理，必須要能夠從更多面向來觀察專案的開發品質，進而及早發現風險與問題，這才是專案經理真正有價值的工作，而不是老是在跟客戶電話你來我往的，或者滿口抱怨專案問題很多，卻無法看出問題究竟出在哪裡，要如何改善。

請點選上圖檢視全圖

上面這張圖片是在專案開發過程中測試人員每日統計的數據做成的報表。

灰色的圖形每日新增的BUG數量，紅色圖形為開發人員已經修正過且交付測試，但並沒有實際解決的BUG。紅色加灰色的數量便是當日發生的BUG總數。金色的圖形則為當日開發人員修正過並且交付的BUG數量。

從這張圖表可以看出，在這個反覆的前期中，開發人員因為某種因素下，大量提高解決BUG的績效，但是我們重測試人員每日測試的結果可以看出，開發人員交付的程式有很高的比例是不通過測試而又重新開啟了一次BUG。結果開發人員就像是在跟測試人員賽跑似的，在反覆的前期造成了惡性循環，最後在最顛峰的時候，幾乎大部分的BUG都是已經修正過卻又重複發生的。

專案經理觀察每日的測試報表之後發現了這個問題，瞭解到開發人員的狀況，於是希望開發人員能夠降低BUG修正的數量以確保工作的品質。調整專案進行的方式之後成效良好，真正的新BUG其實在專案早期就已經發現的差不多了，只要專案人員能夠耐住性子做好修正BUG的品質，最後BUG成長的速度變得到了控制。

當然，筆者要特別說明，上面這張圖只是為了強調專案經理在專案開發過程中要善盡監控的工作，現實狀況下不太可能有這樣如同八點檔連續劇的劇情，高潮跌起。

反覆與調整

許多人一直在講反覆式開發，卻又沒辦法說出反覆式開發的精神與優點出來（當然，瀑布式的缺點講得倒是淋漓盡致）。老實說，筆者目前參與的專案並沒有特別強調是什麼樣子的開發方式，但是就精神來看，我們將專案切成了一個一個週期，在既有基礎上一段一段的交付成品。這點倒是很有那麼反覆式開發的味道。

每次的週期之中，我們可以善盡監控與觀察的工作，當我們發現專案的開發似乎出現了問題，通常並沒有辦法即時去改變現狀，但是卻可以藉由週期的段落會議來討論是否要調整專案進行的方式，是不是流程出了問題，還是不同角色配合的方式銜接不上。我們是否花了太多精神在處理不重要的工作上，PAPER WORK是不是浪費了太多時間，造成了大家工作上的困擾。這些問題都可以在一個個的反覆之中進行調整，這個就是反覆式開發的精神所在。我們可以不用非要等到專案結束了才來埋怨專案為何不順利，而且那往往已經是半年之後的事情了。

故事的最後

在童話故事裡，故事的最後總是如此的美好。但是在專案的開發卻往往不是如此，故事的最後總是客戶總是心不甘情不願的簽了驗收單，專案成員開始打開履歷表準備換個環境，專案經理並沒有從一次專案過程中學習到有用的經驗，瞭解到如何讓下次專案運作的更順暢。

測試只是專案許多環節中的一環而已，與其去控制BUG修正的品質，倒不如在專案開發先期確保專案的基礎能夠穩固，而測試則是能為我們專案開發的成果背書。當我們看到測試的報告時，最好是可以面帶微笑，心中泛起了一點點的成就感，那麼一切的努力也才有了回報。