線上學校 EdTech 平台

客戶是一個線上教育平台，提供互動課程、作業、學生與家長個人帳戶，以及線上付款。業務有明顯季節性：九月是新生最多的時期，開學前幾週平台停擺就代表永久失去客戶。公司沒有內部 QA 團隊，開發人員只能在其他工作之間自行測試；發布前回歸測試要花三天，仍會漏掉付款、課程預約和進入教室等關鍵情境。客戶在一次付款故障造成學校流失部分夏季報名名單後找上我們。

從零建立品質保證流程：

依業務風險安排測試優先順序、自動化關鍵情境、將檢查整合進 CI，並在九月高峰前進行負載測試。限制是不能停止開發：版本仍每週發布，而九月不會等人。

我們沒有從自動化測試著手，而是先做風險分析：哪些情境最常出錯、哪裡出錯成本最高。自動化工作嚴格依照這份清單進行。

• 稽核品質：分析過去半年的錯誤、訪談各團隊，整理問題最嚴重的情境：付款、課程預約、進入教室和家長通知。
• 撰寫測試策略：制定測試層級、責任範圍、功能完成定義和錯誤回報規範，讓三個開發團隊一致遵循。
• 自動化關鍵路徑：使用 Playwright 為網頁平台建立 E2E 情境、為後端建立 API 測試，並在每次發布前執行 smoke 測試集。
• 將 QA 閘門整合進 CI：smoke 測試未通過就不能發布；完整回歸測試每晚執行，結果會在 GitLab 提供所有團隊檢視。
• 以 k6 進行負載測試：模擬九月高峰流量、找出瓶頸，並在旺季前與後端團隊一起排除。
• 將流程移交給客戶：提供文件與規範，並訓練 QA 工程師使用自動化測試和流水線。

關鍵決策是依業務風險排序，而非追求看起來「漂亮」的覆蓋率。我們刻意沒有追求 100% 自動化：關鍵情境覆蓋率達到 75% 就帶來大部分效益，因為保護的是平台創造營收或流失客戶的關鍵流程。其餘部分則在重要發布前以人工探索式測試補足。

建議平台下一步採取：

• 視覺回歸測試：自動檢查課程、電子郵件和個人帳戶的版面。
• 測試資料工廠：每次執行都產生逼真的學生、班級和付款資料。
• 正式環境 QA：使用 feature flags 和金絲雀發布，逐步啟用新功能。