先來說現在測試的故事

在昨天終於我們把寫好的功能做了交付，並且把user story狀態改為交付測試，以及把assign指給了使用者。接下來當然就是要測試了。但測試這個詞說的簡單，卻是可以延伸到非常深的學問的。

筆者曾經待過的公司中，說實話只有在電子廠有測試團隊(QA+QC)，在這裡是沒有的。在這裡基本上就是把使用者的需求，雙邊談好後，交付給使用者進行測試，使用者測試驗收如果通過，雙方蓋蓋章，最後就上線了。

在CMMI流行的地方，就有無限多的文件要製作，因此免不了要製作所謂的開發人員測試文件，以及使用者測試文件。雖說聽起來很奇怪，但這兩份文件基本上就是拿來證明，我開發人員有把功能寫完，而且測試過，有跟我們當時談定的需求符合，以及我需求單位有把你寫完的功能測試過，且有符合我想要的內容，願意驗收。

這聽起來其實沒有太大毛病，開發人員開發完，自己先測試完證明我有把東西寫完，把測試的過程截幾張圖寫成文件，附到工單系統交由開發主管檢查後蓋章同意，將工單系統流程指項user交付測試。

user拿到工單後，針對自己開出來的需求進行測試，把測試的過程也截幾張圖寫成文件，最後附到工單系統交由user主管檢查後蓋章同意，最後工單系統指回給資訊單位進行上線的作業。

整件事情聽起來好像很完整，但實際上在實行時總是會遇到鬼故事。

測試工具的貧乏與文件的品質

不論是開發人員或是user的測試文件，都是使用截圖的方式，寫上文字來敘述測試的過程，這其中就很倚賴測試者到底對記錄做得有多詳細來決定這份文件的完整度了。

我曾經看過令人敬佩的測試者，先不論測試的方法論以及test case的涵蓋範圍，光是他願意努力把所有步驟都截圖下來，寫成一本字典的這種精神就已經令人敬佩了。

但金融業畢竟所有的事情都要管制，特別是發給你的公司電腦，是不能夠亂裝軟體的（我們甚至有些單位 win + shift + s是無法使用的）。因此，上面那位偉大的測試者，使用了print screen + 小畫家，最後修圖後貼到word檔案上，這個工作之繁重，我相信絕對造成測試者相當大的壓力與負擔。

再者，並不是所有的人都願意把自己的時間投入在測試這項工作，因此常常會看到開發人員的測試報告，可能花了2小時進行了測試與文件製作，工單系統流程終於經過審核到了user身上。user竟然可以用20分鐘就可以把報告做完，然後經過審核叫開發人員可以準備上線了。

正當開發人員十分好奇的打開工單系統看到底user有甚麼天生神力，可以把使用者測試報告在這麼短的極限時間產出，結果通常不是內容貧乏，甚至有些就是從開發人員做的測試報告盜圖+盜文字，然後就給主管蓋章後，回指向資訊單位。

痛苦的流程與可怕的稽核缺失

同我之前說過的，我們的工單系統有流程，版本控管系統也有流程，然後版本控管系統又只有正式環境才可以用，測試環境根本就是各憑本事去進行版控的。這就造成了常常會被質疑，你給user測試的這個版本，真的是你放到版控系統的版本嗎？

金融業除了有高度監管的主管機關，另外還有一種角色是會令人聞風喪膽的，那就是稽核。上面那種情境，其實就是非常令人頭疼的狀況。因為版控系統包含了流程，因此你並沒有辦法隨意修改你要異動的程式，因為要經過主管同意。但是版控系統又只負責提供給生產環境過板使用，所以就變成了：

1. 我需要各憑本事在開發把程式寫好並且做好自己的板控，然後申請流程把程式碼簽入第一版到版本控管系統，之後再把該版本系統的程式碼簽出，用手放到測試環境，然後開始做開發人員的測試文件（word），上傳到工單系統，把流程指向科長。
2. 科長確認開發人員測試文件，並將工單流程放行到使用者。
3. 使用者進行測試：
   1.測試有問題，將使用者測試文件（word）附上退回工單系統，剛剛上面講的全部重做一次。
   2.測試沒有問題，製作使用者測試文件（word）附上工單系統，將工單放行到使用者主管。
4. 使用者主管確定測試文件沒有問題，將工單系統放行回開發人員。
5. 開發人員後續準備其他上線文件，包含程式碼比對清單（word），程式上線申請書（word）。

如果你所附上的文件，時間序不對（文件上的填寫日、截圖的電腦時間、工單系統上的時間註記或是版控系統上的時間註記），你就非常有可能被記缺失。要知道，缺失是計算在年度KPI中的，不管是組織或是個人，這會造成個人年度考績的扣分（也就是年終獎金會....）。

而且有了缺失，就要有改進措施，就很容易又請文管單位把SOP修嚴格，來解稽核缺失議題。那因為越來越長，或是越來越多本的SOP，就越來越不會有人看，所以就會造成下一次的稽核缺失，就會周而復始不斷惡化。更甚者，就會變成不做不錯，那就乾脆大家都不要做。 反正你拚了一年結果被記缺失，我啥都不進展沒有缺失，搞不好考績還不會比較低。

日益複雜的人工流程必然發生的錯誤

其實上面的敘述，大概可以歸納成兩個方向來看：

1. 多工具的摩擦： 版控平台無法在開發協助版控，而且管理需求的工單系統也有自己的，導致沒有做到single source。進而導致開發人員、使用者、測試環境、生產環境之間流程的摩擦。
2. 過於繁雜的人工流程： 大量的人工流程，且由第二單位未評估可行性的前提，生產出文件內容繁瑣與複雜SOP。這樣造成開發人員大量的開發外的負荷，包含了流程、程式版本、文件、佈署作業等。要知道，認知負荷在超出的狀況下，是無法在正常將資訊全然記下的，所以就造成了缺失->考績低落->信心降低->人員離開。

筆者在這個單位多年，離職人員多有此抱怨，但我認為開發人員都屬於比較默默地走的人格特質為主，因此上層並未注重過此類問題。

現在，透過Azure Devops，我們先實現了single source，期許能將時間序與版本的問題做一個解決外，再來透過Test Plan這個功能看能完成任務到甚麼程度。