オンラインスクールのEdTechプラットフォーム

顧客は、インタラクティブ授業、宿題、生徒と保護者のマイページ、オンライン決済を備えたオンライン教育プラットフォームです。事業には強い季節性があり、9月に新規受講者が最も増えます。新学期の最初の数週間に停止すれば、顧客を失い、戻ってこない可能性があります。社内にQAチームはなく、開発者が他の作業の合間にテストしていました。リリース前の回帰テストに3日かけても、決済、授業予約、教室へのログインといった重要なシナリオを見逃していました。決済バグにより、夏に集めた申し込みの一部を学校が失ったインシデントを受け、顧客から相談がありました。

品質保証プロセスをゼロから整備します。ビジネスリスクに基づく優先順位付け、重要シナリオの自動化、CIへのチェック統合、9月のピーク前の負荷テストを行います。開発を止められないことも条件でした。リリースは毎週続いており、9月を待たせることはで

きません。

自動テストからではなく、リスク分析から始めました。どのシナリオが最も頻繁に壊れ、どこでバグの損失が最大になるかを洗い出し、そのリストに沿って自動化しました。

• 品質を監査しました。直近半年のバグを分析し、各チームに聞き取りを行い、決済、授業予約、教室へのログイン、保護者への通知といった問題の大きいシナリオを整理しました。
• テスト戦略を作成しました。テストレベル、責任範囲、機能の完了条件、バグ報告手順を定め、3つの開発チームで統一しました。
• 重要な経路を自動化しました。WebプラットフォームにはPlaywrightのE2Eシナリオ、バックエンドにはAPIテストを導入し、各リリース前にスモークテストを実行します。
• QAゲートをCIに組み込みました。スモークテストが成功しなければリリースできず、完全な回帰テストは毎晩実行され、結果はGitLab上で全チームが確認できます。
• k6で負荷テストを行いました。9月のピーク流量を再現してボトルネックを見つけ、シーズン前にバックエンドチームと解消しました。
• プロセスを顧客側へ引き継ぎました。ドキュメントと運用手順を整え、QAエンジニアに自動テストとパイプラインの使い方をトレーニングしました。

重要な判断は、見栄えのよいカバレッジ率ではなくビジネスリスクで優先順位を付けることでした。100%自動化は目指しませんでした。重要シナリオの75%をカバーすることで効果の大部分を得られました。プラットフォームが収益を得る、または顧客を失う経路を守れたからです。残りは重要なリリース前に手動の探索的テストで確認します。

プラットフォームに次に推奨する施策：

• ビジュアル回帰テスト。授業、メール、マイページのレイアウトを自動で確認します。
• テストデータファクトリー。実際に近い生徒、クラス、決済データを実行ごとに生成します。
• 本番QA。feature flagsとカナリアリリースで新機能を段階的に有効化します。