高鐵售票程式一團亂 誰的責任？
沒有測試到嗎？
不論系統是改別人的、還自己開發的、大包商負責的、還是小包商負責的、老鳥設計撰寫、或是菜鳥設計撰寫的，理論上，在系統上線前應該會經歷一連串的測試。主要分成系統開發時以及上線前的測試：每一個小模組修改或撰寫完的時候，程式設計師會針對自己所撰寫或所修改的程式來進行測試；一堆模組撰寫或修改完成並且組合後，系統分析師就會介入測試這些模組組合在一起後是不是有問題需要被調整。最後，當整個系統完成後還會有幾次的壓力測試。
基本上系統廠商為了保障自己的商譽，所以自己內部可以會先針對系統的弱點（因為系統是自己設計的，所以自己會比較清楚弱點在那邊）進行壓力測試。等到一切都沒有問題了，才會把系統交付到客戶的手中，再依客戶所提的需求來進行壓力測試。
經過了這麼多的測試，沒有測出系統重複給位的問題，這是誰的問題？首當其衝的，高鐵應該要負第一個責任，但說老實話，我不覺得高鐵的責任最大，User之所以為User就是因為他沒有能力成為Developer。或者換一個角度來說，高鐵的主力應該是focus在他在高速鐵路的經營管理上面，這才是他們的專業。因此系統維運應該是高鐵系統技術部門的責任，但談到系統開發，他們沒有那麼熟悉倒是可以被接受的。
「測試」是系統開發中重要的一環，個人設計撰寫的程式，都免不了要自己先小測一下；而多人共同開發的系統程式，測試就更不可或缺，以避免初期規劃上的瑕疵。不過，測試的廣度與深度會隨著測試者本身的經驗有很大差異；同樣的系統、同樣不是自己撰寫的程式，有些測試者沒有辦法發現系統中的漏洞，可是較有經驗的測試者往往一測就可以抓出一些罕為人知的問題。
台灣的系統廠商有時候會很不重視這一個測試這一個環節，因為「測試」本身看起來並不具生產力，所以往往是程式寫完了就直接丟給使用者去測，但不幸的，使用者並不一定十分了解這一個系統規劃，因此測試的時候，也頂多UI（User interface，使用者操作介面）測一測看有沒有順就好了，至於系統運作上的盲點，一般的使用者是沒有能力去測的。
所以問題還是回歸到系統開發廠商身上，測試人員是否有足夠的經驗來規劃及進行系統全面性的測試？還是他們只是跟一般的使用者一樣，使用者介面測一測就放行了呢？如果真的測得夠深入，方式也夠全面，那為什麼會有重複劃位的情況產生呢？我想台鐵售票系統這個案例不只在系統設計與開發上是一個好的提醒，也在「測試」的這一件事上是一個好的教案。
是故，談到高鐵售票系統的測試，ㄟ…我相信高鐵人員應該是有測過，也應該對UI做了很多調整—所以他們才可以在維運後，很順利地操作系統、很用力地賣票，甚至連賣出重複劃位（而且還劃了三次）的票還渾然不知。
只不過，開發廠商的測試人員可能也對會有話要說：「…專案經理交待的測試我都做了啊！…」
專案經理的責任？
專案管理中，專案規格確認與風險掌握是專案成敗的關鍵因素。所以理論上，在專案規格的部份，專案經理或多或少會參與系統分析師的作業以確保規格上沒有瑕疵；而在風險管理的部份，專案經理應該盡可能地把可能造成風險的例外狀態的預想出來，以做好風險的管理，必要時透過測試的規劃以減少例外狀況的產生。
那高鐵售票系統的「一位三賣」算是「例外」還是「常態」呢？這就是這一個案例有意思的地方。售票系統「一個位子不可以賣三次」這個規範，對於老經驗的技術人員而言根本是 common sence ，所以有可能不會在規格(spec.)上特別去規範，對風險管理與測試規劃的部份，因為是「common sence」所以理論上它是一個「常態」，因此具有規劃經驗的專案經理應該不會把這樣的「常態」條列在風險管理之中。
這個案子很「神」的地方就在於一般被認為是「常態」卻成了「例外」。不過，如果專案經理的經驗夠豐富，一開參與軟體規格制定的時候，他就會事先意識到這樣的問題，所以即使是視為「common sence」而沒有特別定義在文件中，也會利用先前的規格制訂作業或之後的壓力測試來把這個問題突顯出來。
在什麼樣的情況，專案經理會沒有注意到這些問題呢？第一種、在專案經理過度信任系統設計、開發、測試人員。第二種就是專案經理其實沒有足夠的軟體開發專業知識或經驗以至於他有足夠的敏感度來「發現」這個問題。我不是很確定高鐵售票系統的開發廠商所面臨的是什麼樣的難處，不過，上述的第二種情況是滿值得被探討的。 （未完，請繼續最後一頁）
|