測試品質與使用者體驗：從需求到驗收的風險管理
題面來自台大官方試卷；解析與逐項自評標準（rubric）為本站依已複查來源整理的非官方內容，策略申論容許有條件且有證據的替代論點。
考古題證據邊界： 考古題只證明此範圍曾出現；題面均為申論或開放題，答案非官方，課程練習採 rubric self-review，絕不進自動計分或完整模擬考。
第一次接觸也沒關係
這堂先懂這些詞
先記住白話意思，不必急著背英文。看到正文時，再把正式名稱接回來。
Scrum
也會看到：Scrum framework用短週期、透明檢查與調整來處理複雜工作的敏捷框架。
- 生活例子：
- 每兩週完成可試用的小改版，再依回饋調整。
- 別搞混：
- 不是一套固定瀑布流程，也不是每天站會的別名。
單元／整合／系統／使用者驗收測試
也會看到：unit testing、integration testing、system testing、UAT依序檢查小零件、零件介面、整套系統，以及業務是否願意接受。
- 生活例子：
- 先測水龍頭、再測整段水管、再測全屋供水，最後由屋主驗收。
- 別搞混：
- 全部技術測試通過仍可能做錯需求。
使用者體驗
也會看到：UX、User Experience人在使用產品前、中、後的整體感受與完成目標的容易程度。
- 生活例子：
- 網路購票是否找得到班次、看得懂價格並順利付款。
- 別搞混：
- 不只是畫面漂亮。
深入測試策略設計與使用者體驗評估，重點在如何用測試降低交付風險、用 UX 研究確保做出使用者需要的產品。
先抓住這幾件事
- 設計分層測試策略（test pyramid）並解釋各層的成本效益
- 區分 verification（做對了嗎？）與 validation（做對的東西了嗎？）
- 運用 Nielsen 的可用性啟發法評估介面設計
- 設計使用者研究計畫（persona、journey map、usability test）
1.測試金字塔的成本效益邏輯
Test pyramid 不是教條——它是根據回饋速度和定位能力做出的經濟判斷。底層多 unit test 的原因：(1) 快——一個 unit test 可能只需 1 毫秒，10,000 個 unit test 在 10 秒內跑完。開發者每次修改程式碼後立即知道是否破壞了什麼。(2) 便宜——不需要外部服務、資料庫或網路。(3) 穩定——不依賴外部環境，不會因為測試環境不穩定而「假失敗」（flaky test）。(4) 容易定位——失敗時精確指出是哪個函數哪一行出問題。 頂層少 E2E test 的原因恰好相反：慢（可能需要啟動瀏覽器、資料庫、多個服務，一個測試幾十秒到幾分鐘）、脆弱（任何環節不穩定都可能失敗——UI 改了、資料庫清空了、第三方服務掛了）、難定位（失敗了但不知道是前端、後端、資料庫還是第三方的問題）。但 E2E test 的優點是最接近使用者的真實行為——它測試的是整個系統協同工作的結果，不是單一元件的邏輯。 反轉的 ice cream cone 模式（大量 E2E、少量 unit）是很多組織的現實——因為 E2E 測試看起來「更有信心」（畢竟測了整個流程），但長期代價是：CI/CD 管線速度慢（每次修改要等 30 分鐘跑 E2E）、維護成本高（UI 改了所有 E2E 都要更新）、假失敗多（團隊開始忽略失敗的測試，測試失去意義）。 考試常見：解釋 test pyramid 的設計邏輯、分析某組織的測試策略問題。不要只畫三角形——要說清楚每層「為什麼多」或「為什麼少」的經濟原因。
- Unit test 多的原因：快（毫秒級）、便宜（不依賴外部）、穩定（不 flaky）、容易定位
- E2E test 少的原因：慢（啟動完整環境）、脆弱（任何環節不穩定都會失敗）、難定位
- Ice cream cone（大量 E2E 少量 unit）的代價：CI/CD 慢、維護貴、假失敗多
- Test pyramid 是經濟判斷不是教條——不是所有情境都適用（例如 legacy code 可能先寫 integration test）
- 不只畫三角形——解釋每層多或少的經濟原因才能拿分
2.UAT 是 validation，不只是最後一關 testing
UAT（User Acceptance Testing）回答的問題和其他測試完全不同。Unit/integration/system test 回答「Are we building the product right?」（我們做的東西是否正確實現了規格書？）——這是 verification。UAT 回答「Are we building the right product?」（我們做出來的東西是否是使用者需要的？）——這是 validation。兩者的區別是考試高頻考點。 一個完美通過所有 unit/integration/system test 的系統，如果需求本身是錯的（使用者其實不需要這個功能、流程設計不符合實際工作方式），仍然是一個失敗的系統。所以 UAT 不只是「最後一關測試」——它是唯一一個能發現需求層面問題的環節。 UAT 的品質取決於三個條件：(1) 參與者是真正的使用者——不是開發團隊冒充使用者，不是管理者代替使用者。(2) 使用真實情境和資料——不是預設好的「正常案例」，要包含 edge cases 和異常情境。(3) 有明確的 acceptance criteria——在需求定義階段就寫好（例如「使用者能在 3 步驟內完成退貨申請，每步驟等待時間不超過 2 秒」），UAT 時依據這些 criteria 判斷通過與否。 缺陷的修復成本與發現時間的關係（Boehm 的研究）：需求階段發現的缺陷修復成本 = 1x，設計階段 = 3-6x，程式碼階段 = 10x，系統測試階段 = 15-40x，上線後 = 40-1000x。這就是為什麼 shift-left testing（盡早測試）不只是口號——它有明確的經濟邏輯。 考試提醒：verification vs validation 是必考題。回答時要用具體例子說明兩者的差別。
- Verification = building the product right（對規格）；Validation = building the right product（對需求）
- UAT 是唯一能發現需求層面錯誤的環節——所有其他測試只能驗證規格
- UAT 三要素：真正的使用者、真實的情境和資料、事先定義的 acceptance criteria
- 缺陷修復成本隨發現時間指數增長：需求階段 1x → 上線後 40-1000x（Boehm）
- Shift-left testing 有明確的經濟邏輯——不只是口號
3.UX 研究不是「問使用者喜歡什麼」
UX 研究的核心原則是：使用者說的（attitude）和做的（behavior）經常不同。使用者可能說「我覺得這個設計很好用」，但在實際操作時反覆迷路、點錯按鈕、看不到重要資訊。所以 UX 研究需要同時使用 attitudinal methods（態度研究）和 behavioral methods（行為研究）。 行為研究方法：Usability test（可用性測試）——讓 5-8 位使用者完成真實任務，觀察他們的操作行為、卡住的地方和錯誤。Jakob Nielsen 的研究發現 5 位使用者就能發現約 85% 的可用性問題。A/B test——隨機分流，比較兩個版本的業務指標（轉化率、完成率、跳出率）。Analytics（行為分析）——透過 click tracking、heatmap、funnel analysis 等工具量化使用者的行為模式。 態度研究方法：使用者訪談——深入了解使用者的需求、動機、挫折和期望。Survey——大規模蒐集使用者意見。Card sorting——讓使用者按照自己的理解分類資訊，用於設計資訊架構和導航。 設計工具：Persona 從研究資料歸納出使用者原型——不是想像出來的虛構人物，而是基於實際研究的行為模式和需求概括。Journey map 記錄使用者完成任務的完整流程：每個 touchpoint（接觸點）、使用者的 emotion（情緒）、pain point（痛點）和 opportunity（改善機會）。 Prototype 的 fidelity 應該匹配研究目的：概念驗證用低保真（紙本原型、線框圖），互動測試用高保真（可點擊的原型）。用高保真原型做概念驗證會浪費時間，用低保真原型做互動測試會得到不準確的結果。
- 使用者說的（attitude）和做的（behavior）經常不同——需要同時用兩類方法
- 5 位使用者的 usability test 可發現約 85% 的可用性問題（Nielsen 研究）
- Persona 基於研究資料歸納，不是想像出的虛構人物
- Journey map 記錄 touchpoint、emotion、pain point、opportunity
- Prototype fidelity 匹配研究目的：概念驗證用低保真，互動測試用高保真
4.Nielsen 十大可用性啟發法的實務應用
Nielsen 的十大可用性啟發法（10 Usability Heuristics）是 UX 評估的經典框架。它不是檢查清單——而是一組設計原則，可以用來分析和改善任何互動式系統。MIS 考試中最常用到的幾條： (1) Visibility of system status（系統狀態可見性）——使用者應該隨時知道系統在做什麼。例如：上傳檔案時顯示進度條，提交表單後顯示成功/失敗訊息，處理中顯示 loading indicator。違反的例子：使用者按了「提交」按鈕但畫面沒有任何反應，不知道是否成功。 (2) Match between system and the real world（與真實世界的對應）——系統使用使用者熟悉的語言和概念，而不是系統內部的技術術語。例如：用「購物車」而不是「暫存訂單列表」，用「最近瀏覽」而不是「瀏覽歷史佇列」。 (3) User control and freedom（使用者控制和自由）——使用者需要「緊急出口」。例如：undo/redo 功能、返回按鈕、取消操作的能力。沒有 undo 的操作（如永久刪除）需要確認對話框。 (4) Error prevention（錯誤預防）——比 error message 更重要的是從一開始就防止錯誤發生。例如：日期選擇器比文字輸入框更能防止格式錯誤、灰掉不可用的選項比事後報錯更好、表單即時驗證比提交後才報錯更好。 (5) Consistency and standards（一致性和標準）——內部一致（系統內相同操作的行為相同）和外部一致（符合平台和產業慣例）。例如：iOS app 的返回按鈕在左上角是外部慣例，如果你放在右上角會讓使用者困惑。 申論中用 Nielsen 啟發法的方式：給一個系統的 UI 截圖或描述，辨識它違反了哪幾條啟發法，說明違反的後果（使用者會有什麼困惑或錯誤），然後提出改善建議。這是 MIS 考試中少數可以拿「分析→辨識問題→建議」高分的題型。
- Visibility of system status：使用者隨時知道系統在做什麼——loading、success、error 都要顯示
- Error prevention 比 error message 重要——日期選擇器、灰掉不可用選項、即時驗證
- Consistency & standards：內部一致（同操作同行為）和外部一致（符合平台慣例）
- Nielsen 啟發法不是檢查清單——是設計原則，用來分析和改善任何互動系統
- 申論用法：辨識違反哪條→說明後果→提出改善——這是高分的分析→建議題型
一起搭作答骨架
範例 1：如何回答「測試品質與使用者體驗」的比較題？
- 定義比較軸與分析單位。
- 各寫一條作用機制。
- 加入至少兩項條件或風險。
- 用案例與指標驗證。
所以作答主軸是：可接受的答案不只一種；關鍵是條件透明、概念正確、推論可追蹤，並能說明限制。
範例 2：題目要求提出建議時，如何避免只列 buzzwords？
- 先指出要改善的問題。
- 說明建議如何改變流程、資訊或激勵。
- 指定責任人與衡量方式。
- 補上失敗訊號與替代方案。
所以作答主軸是：建議應包含 action、mechanism、metric 與 risk，而不是只寫「導入 AI／雲端／平台」。
這裡最容易寫偏
- 把工具名稱當成因果解釋
- 沒有說明分析層級與前提
- 只寫單一立場，不處理權衡
- 把非官方參考解析當唯一標準答案
- 引用時事卻沒有日期與來源邊界
換你快速判斷
先用自己的話說出定義、機制、條件與取捨，再展開答案。
最後用考古題自評
請先完成自己的申論，再依非官方解析和逐項自評標準檢查；不使用 A–E 假選項或虛假分數。
開始本課申論自評參考來源
- Management Information Systems: Managing the Digital Firm, 17th Edition — Kenneth C. Laudon; Jane P. Laudon
- 10 Usability Heuristics for User Interface Design — Jakob Nielsen