Code Bank

由於系統開發的速度越來越快，軟體的生命週期(SDLC)也隨之越來越短，從規劃、設計、程式開發、測試到上線(Go Live)，通常不會超過半年，如果採用傳統的瀑布式(Waterfall)開發，每個階段可能只有短短一個月的時間，因此，通常要使用並形式的開發方式，不管是重疊式、螺旋式、漸進式，總之，就是要想辦法盡速跑到終點。但是，如果不顧品質，匆忙上線，通常是一場災難，搞得團隊烏煙瘴氣、徹夜加班，因此如何提升開系統發品質是專案不可或缺的工作，這就是Test Data Management (TDM)的訴求。

品質是管理與測試出來的，唯有良好的專案管理及周延的測試才是品質的保證，其中測試分三階段:單元測試、整合測試及系統測試，單元測試(Unit Testing)是程式設計師的責任，通常採取迴歸測試(Regression Test)，即設計測試案例，再經由測試工具或人工執行，在每次改版時，重新檢驗這些測試案例，為提升這一方階段的品質，而有所謂的Test-Driven Development(TDD) 開發方式；整合測試(Integration Testing)是整合多個模組，作較大範圍的測試，例如單一流程的測試，系統測試(System Testing)則是針對整個系統作全面性的測試，常常與UAT(User Acceptance Testing)合併；整合測試與系統測試都需要完整的測試環境，亦即要佈署整個系統供測試人員及使用者測試，，這就是Test Data Management (TDM)的訴求的階段。

要佈署測試環境或平行測試(Staging)環境，除了程式本身以外，測試資料也非常重要。程式的佈署強調Continous Intergration/Continous Delivery，從程式的修改、版本控制、Issue Tracking到程式佈署、測試，整個流程一貫化，以縮短測試/上線時程，使用VM/Docker或雲端快速佈署，也是一個好的方法。

而測試資料的準備，也有幾個層面要考慮:

1. 測試資料要配合測試案例，要能表現各種測試情境(Scenario)。
2. 測試資料要遮掉(Mask)敏感性資料，亦即重要個資或企業機密，應避免放入測試環境，以免資料外洩。
3. 測試資料必要時，須隨時間而更新，以反應現實狀況。
4. 測試資料量需為能完整測試的最小量。

基於以上的情境，如何使用ETL工具及測試資料產生器，也是測試人員很重要的課題。

我們常常因為專案時程緊迫，而忽略了完整的測試就更版或直接上線，代價就是在維護階段產生開發成本的12倍代價，相對於設計階段發現Bug，只花兩倍的代價，所以，一個未經完整測試的系統，它的維護成本有如冰山，十分之九都隱藏在水面下(Sunk Cost)，這就是典型的『欲速則不達』，這就是這幾年TDD、CI、CD、Docker極力訴求改善流程的原因吧。