CISA D3 系統導入:測試、移轉、導入後審查最常錯的 10 個觀念

D3 的導入這一半(測試、移轉、上線、導入後審查)讀起來像常識,題目卻很會把「對的事放在錯的時點」或「對的事交給錯的人」做成選項。這篇整理 10 個最常選錯的觀念,附考法和分辨方式。

例子用的是我們自己寫的練習題。遇到題目先問兩個問題:現在停在哪個階段?這件事該誰簽?

測試:先分清楚誰測、依什麼測

• 1. 四個層級:單元測試只測一個模組,通常用白箱、由開發人員做;整合測試驗證模組之間的介面與資料傳遞;系統測試依系統規格,由 IT 的測試團隊做,含效能、安全、復原等非功能面;使用者驗收測試(UAT)由使用者依業務需求和驗收準則做,通常是上線前最後一關,要使用者簽核。陷阱:開發人員做 UAT,或拿單元測試證明介面沒問題。

• 2. 配對題看目的:問「最能證明什麼」,就照目的配:滿足業務需求選 UAT,符合系統規格選系統測試,新系統不干擾同環境的既有系統選共存性測試,修改後沒弄壞原功能選迴歸測試,找安全弱點選弱點掃描或滲透測試。陷阱是「也是測試,但測不到這個目的」,例如拿壓力測試或迴歸測試證明安全。

移轉:四種策略和退路

• 3. 取捨題抓關鍵字:問新舊結果是否一致,選平行運行;問怎麼降低一次切換的風險,選分階段或試點。陷阱:拿平行運行去比效能或省成本,或把分階段和試點混為一談。分階段切的是功能,試點切的是單位。
• 4. 沒有退路最危險:切換計畫要明訂「繼續或回退」的判斷點,回退計畫要在變更核准前備妥,不是出事才想。沒有回退計畫的切換風險最大,重大變更缺回退程序,是稽核常見的發現。

資料轉換:總數對了,不等於每一筆都對

• 5. 怎麼驗證:要證明沒遺失、沒重複、沒被改,比筆數、金額合計、核對和,再抽樣逐筆比對;也可以拿歷史交易在新系統重跑,對照舊結果。陷阱是「總數對了就沒事」:筆數和合計只證明整批對得上,題目問「每一筆(像個別帳戶餘額)對不對」,要選抽樣逐筆比對。
• 6. 先後順序:第一步是先弄懂新系統的資料結構,才訂得出對應規則、知道要清什麼,所以問「最先」時,清理和轉換都排在後面;清理則要在轉換之前完成。轉換規則先定義好,轉換途中要改資料,得經業務擁有者核准。要證明轉換行得通,用正式資料的副本在受控環境完整演練一次(模擬轉換),比只審查程序文件有說服力。比較上線風險時,資料轉換出錯和測試不足通常比訓練不足嚴重。

組態、釋出與上線核准

• 7. 上線的東西要對得到核准:組態基準是某個時點經核准的組態,定期拿實際組態去比對,才抓得到偏移和未授權的變更。釋出管理要確認上線的就是核准並測試過的那一版,即預備環境驗證通過的同一版;開發人員不該有正式程式庫的寫入權限。緊急變更可以先做,但要留紀錄、事後補核准並檢討;陷阱是緊急時還要求事前層層核准,或只留紀錄不補核准。

• 8. 上線核准誰簽:由承擔業務後果的人簽,也就是使用者管理層或指導委員會,不是開發團隊,也不是 DBA、系統管理員或專案經理。簽之前要確認測試完成、重大缺陷處理好、測試用權限清掉、回退計畫備妥。常被混淆的是認證和認可:認證是依標準做的評估,認可才是權責主管據以決定上線並接受剩餘風險的決策。稽核人員只確認該簽的人有簽,不替他簽。

導入後審查:看效益與控制

• 9. 它不是驗收:導入後審查在上線之後做,檢視需求有沒有滿足、效益和成本有沒有達到商業論證的估計、控制有沒有效、使用者滿不滿意。題目問上線後要確認系統照設計運作,選它,不選 UAT;要看上線後系統本身的內建控制和存取控制組態,選項若是回頭評上線前就做完的測試,多半是干擾項。

• 10. 時機和獨立性:通常要等上線後至少過一個完整處理週期、效益量得出來才做;專案團隊、使用者或稽核人員都能做。陷阱是以為參與過就一律不獨立:損及獨立性的,是自己設計、導入或操作過該系統控制的人;只是列席觀察,或以沒有營運職責的成員身分提控制建議,不算。