検証ブロッカーチェックをビルドパイプラインに組み込んだ話

はじめに

はじめまして。QA歴3年目の者です。
先日のGREE Tech Conference 2024（以下、GTC）で、「実機ビルドのエラーによる検証ブロッカーをゼロに！『ヘブンバーンズレッド』のスモークテスト自動化の取り組み」を発表しました。
本記事では、発表時の「今後の展望」にも触れた検証ブロッカーチェックをビルドパイプラインに組み込む際のフロー変更点、つまずいた点、そして得られた知見を共有します。

ビルドパイプラインとは

アプリケーションのビルド（構築）からテスト、デプロイ（配布）までの一連の作業を自動化する仕組みのことです。

GREE Tech Conferenceとは

グリーでは、さまざま事業領域でサービスを開発・運営するとともに、技術的なチャレンジにも積極的に取り組んでいます。
GTCは、これらのチャレンジを通じて得られた知見や、今後の取り組みを共有する技術カンファレンスです。

▼公式サイト
https://techcon.gree.jp/2024

GTCで発表したこと

まずGTCで発表した内容について簡単に紹介します。

課題

• 検証ブロッカーの発生により、当日テストが実施できない
• QA期間が1日短縮される

補足: 「ブロッカー」とは、ビルドが動作しないなど、テストが開始できない不具合を指します。

解決方法

• ビルド完成直後に自動スモークテストを実施
  （ビルドは夜間に完成することが多い）
• すでに存在していたSlack通知チャンネルを活用し、スモークテストサーバーで常時チャンネルを監視。通知を受け取ったタイミングで自動テストを開始するフローを構築

新たな課題

• Slackがダウンしたり通知が失敗すると機能しない
• Slack通知までにタイムラグが発生する
• ビルド不具合以外の要因でスモークテストが最後まで完了しないケースがある

今後の展望

• ビルドパイプラインへの組み込み
• スモークテストの精度向上

今回は、上記のうち「ビルドパイプラインへの組み込み」について共有します。

ビルドパイプラインへの組み込み

改めて、課題、解決方法、構成図、フローチャートの変更点、つまずいた点、そして得られた知見についてお話しします。

課題

• Slackがダウンしたり、通知が失敗すると機能しない
• Slack通知にタイムラグが発生する

解決方法

• ビルドパイプラインに直接組み込む
  一部のフローをJenkins Jobとして構築しました。この作業はQAチームだけでは対応が難しかったため、エンジニアと共同で進めました。

エンジニアと共同作業を進められた理由

• エンジニアが協力的だった
  プロジェクト全体の品質意識が高く、エンジニア側からの積極的なサポートを受けることができました。
• エンジニアにもメリットがあった
  ビルドパイプラインの改善によって、エンジニア側にも以下の利点がありました。

エンジニアのメリット

• 夜間の作業負担が軽減
  ビルド作成担当のエンジニアが、夜間にビルド完成後の起動確認を行う必要がなくなった。
• 進捗の可視化
  Jenkinsのダッシュボードでテスト進捗を簡単に確認できるようになった。

QAのメリット

• 時間の短縮
  Slackを介さないフローに変更したことで、テスト完了までの時間が短縮された。

構成図

フローチャート

発表時のフローチャート

• Slack通知チャンネルを1分ごとに監視し、「ビルド完成通知が来たか」「キューにタスクがたまっているか」を確認します
• 自動スモークテストは通信環境や端末の挙動によって失敗しやすいため、エラー扱いになった場合は再実行する仕組みを採用しています

ビルドパイプラインへの組み込み後のフローチャート

• Slackを介さず、ビルド完成後に即時自動テストを開始できるようにしました
• Jenkins Job部分は、エンジニアに対応してもらいました

つまずいた点と得られた知見

以下に、「面倒でもやったほうが良い」と感じた点を共有します。

1. Jenkins Job導入時の課題
   • サーバーOSやPythonをバージョンアップする必要があり、インストール済みモジュールが削除されました
   • 解決策
     • 必要なモジュールはリスト化しておく
2. スクリプトファイルの構成変更
   • フローチャートが変更されたことで、スクリプトの構成を見直す必要があり、実装に時間がかかりました
   • 解決策
     • フローチャートを作成し、整理してから実装する
3. 新しいWindows端末での再構築
   • 新しい端末に変わった際、環境再構築に時間を要しました
   • 解決策
     • 必要なモジュールや環境設定をリスト化する
4. エンジニアとの共同作業
   • 資料はあったものの活用されず、質問し合いながら進める形になりました
   • 解決策
     • ミーティング資料には「解決したいこと」「やりたいこと」を明記する
     • 手段やフローはMTG中に補完する

導入した結果

• テスト進捗を確認できるようになったことが、予想外にありがたいと分かった
  • 今までどのビルドがテスト中なのか分かりづらかった
  • テスト完了時間が見通せるようになるメリットがあった

最後に

今回の取り組みは、GTC発表前にとあるエンジニアの方から「Jenkinsパイプラインに取り込めばよくない？」という提案をいただいたことがきっかけで動き出し、実現しました。
Jenkins Jobを実装してくださったエンジニアの方、相談に乗ってくださった方々に感謝します。また、マシン調達や回線確保、社内調整をしてくださった上司にも深く感謝しています。
スモークテスト自動化のアイデアを思い付いたのは2023年1〜2月頃だったため、ここまで時間がかかりましたが、今後は他のチームへの導入も目指していきたいと思います。