はじめに

ペースの速い現代のソフトウェア開発の世界では、高品質なモノを迅速に提供することが不可欠です。従来のテストアプローチでは、不具合やエラーの発見が遅すぎることが多く、修正するためのコストが増えてしまいます。

IBMの調査によると、本番環境で発見されたバグは、設計段階で発見された場合に比べて修正コストが6倍にもなります。

以下のNISTのグラフは、ソフトウェアが開発の5つの主要なフェーズを進むにつれて、不具合を特定し解決するための工数が大幅に増加することを示しています。

これが、シフトレフトテストアプローチの原点です。テストを開発サイクルの早い段階に移行させることで、シフトレフトテストはチームがより早期に欠陥を発見し、コラボレーションを向上させ、デプロイリスクを減らすのに役立ちます。

このブログ記事では、シフトレフトテストとは何か、その利点、導入方法、そして直面するかもしれない課題について掘り下げます。

シフトレフトテストとは？

「シフトレフト」という言葉は、ソフトウェア開発ライフサイクル（SDLC）において、テスト活動をより早い段階（左側）に移行させることを意味します。従来、テストは開発の終盤で行われていましたが、シフトレフトでは要件定義や設計といった初期段階から品質保証（QA）とテストが開始されます。

従来のアプローチ vs. シフトレフトアプローチ

シフトレフトテストの利点

• バグの早期発見: バグは早く発見されるほど、修正が迅速かつ安価になります。

• 市場投入までの時間短縮: 問題を早期に修正することで、リリースを加速できます。

• コスト削減: 開発段階でバグを修正する方が、本番環境で修正するよりもはるかに安価です。

• 連携強化: 開発者とQAが初期段階から密接に連携します。これにより、テストカバレッジの向上、エッジケースの早期検討、セキュリティテストの実施につながります。

PayPayについて

さらに詳しく掘り下げる前に、PayPayとPayPayのQAプロセスについて説明します。

• PayPayは日本で7,000 万人以上のユーザーに使われている、日本を代表する決済ソリューションの 1 つです。

• 当社は毎日 1,000 万件以上の取引を処理し、シームレスで信頼性の高いサービスを保証します。

• PayPayでは、ユーザーの信頼を維持し、優れた体験を提供するために、スピードと品質が最重要であると考えています。

PayPayにおけるテストプロセス

PayPayでは以前、アジャイルアプローチを採用していましたが、QAチームと開発チームの連携はあまり密接ではありませんでした。各機能は、エンドツーエンドで準備が整った時点でQAに引き渡されていました。そのため、QAはバックエンドとフロントエンドの両方の開発が完了し、かつ開発側の統合テストも完了するまで待つ必要がありました。このプロセスは、プロジェクトのリリースを遅らせ、多くの問題を引き起こしていました。

PayPayはマイクロサービスアーキテクチャを採用しているため、以前のテストプロセスはあまり適していませんでした。主にエンドツーエンドテストとUIテストに依存しており、バックエンドAPIテストが十分にカバーされていなかったのです。そのため、当社はあらゆる側面で包括的なテストカバレッジを確保するために、テスト戦略の改善を目指しています。

当社のSDLCプロセスには、要件定義からPRD、技術ドキュメント、開発、統合テストまで、多くのフェーズがあります。そのため、QAチームはこれらのフェーズがすべて完了するまで、プロジェクトの作業を開始することができませんでした。

PayPayのSDLCプロセス

QAは開発フェーズが開始されるまでテストプロセスを開始できませんでした。大まかなテスト計画やシナリオは作成されるものの、テスト実行と自動化スクリプト開発を開始するためには、成果物がすべて出来上がるのを待つ必要がありました。自動化スクリプトは、機能開発のサインオフ後にようやく完成することが多く、回帰テストに必要な労力を増大させていました。また、承認プロセス中にバグが発見された場合、QAはそれらを解決するためにさらにアナログで行う作業を多く強いられました。

PayPayにおけるQAプロセスは、PRD分析、テスト計画、テスト実行、自動化、そしてQAによる承認という流れで進められます。

PayPayのQAプロセス

直面していた課題

• 機能リリースの遅延

• 高い開発コスト

• 開発後期でのバグ発見が多く、品質問題が発生

• エンドツーエンドのUIテストケースが多く、実行するための工数が多く、コストが高い

なぜシフトレフトなのか

PayPayにとって、スピードと品質はどちらも重要であり、ユーザーがPayPayに寄せている信頼を裏切るわけにはいきません。そのため、最新の機能をユーザーに提供するためには、品質を妥協することなく、リリースのペースを早める必要がありました。

それが、QAプロセスにシフトレフトのアプローチを組み込み、試みた理由です。

導入方法

PayPayにとって、QAプロセスにシフトレフトアプローチを導入することは新しい試みでした。加えて、当社のQAチームは主にUIテストケースに注力していたため、QAと開発チームの間にギャップが生じていました。最初のステップとして、このギャップを埋めることが最優先事項でした。

この課題に対処するため、当社はバックエンドテストに重点を置き、マイクロサービスレベルおよびエンドツーエンドのテストをカバーしました。そして複数のプロジェクトに対応するバックエンドテストフレームワークを確立し、個々のマイクロサービスのテストを開始。UIの検証からマイクロサービスのテストへと焦点を移し、個別のAPIや特定の機能のテストを進めました。

この改善を基に、さらに一歩踏み込んで、よりシフトレフトなアプローチを採用しました。あるプロジェクトでは、開発チームがAPIスキーマを確定するとすぐに、自動テストケースの作成を開始しました。これは当社のシフトレフトへの道のりにおける重要な一里塚となり、わずか2週間でバックエンドサービスを完全に自動化し、すべてのフローをテストすることが可能になりました。

PoC（概念実証）段階

当社のシフトレフトの取り組みは、「PayPayポイント（期間限定）」プロジェクトから始まりました。このプロジェクトでは、厳しい納期がある中で新しいバックエンドサービスを開発する必要がありました。

そこで、テクニカルプログラムマネージャー、プロダクトマネージャー、エンジニアリングマネージャーとプロジェクトのテストプロセスについて議論を始め、シフトレフトを提案しました。

シフトレフト導入による新しいアプローチ

早期からの関与

• QAが要件定義およびキックオフの段階から積極的に参加

• 各スプリントおよびSDLC全体を通じて議論に参画

並行プロセス

• QAチームは開発と並行してテスト計画と設計を開始

• APIスキーマが確定され次第、自動化スクリプトの開発を開始

• 開発チームの進捗に合わせて、QAがAPIとフローをリアルタイムで検証

• 開発と並行して、タイムアウトテストを含むネガティブテストに注力

連携強化

• 開発者との定期的なやり取りにより、プロジェクトの理解が容易に

• これにより、バグの特定と解決が迅速化

当社のシフトレフトサイクル

シフトレフトアプローチの利点

シフトレフトアプローチを導入したことで、PayPayとQAチームの両方に大きなメリットがもたらされました。具体的には以下の点が挙げられます。

開発期間の短縮

概算ではありますが、このアプローチでプロジェクトを進めることにより、プロセス全体にかかる時間を30%から40%削減できたと見積もっています。

節約された時間のほとんどは、テスト計画および設計フェーズでの改善によるものでした。開発プロセスの早期から関与することで、QAチームは要件を明確に理解できるようになり、包括的なテスト計画と設計の作成が格段に容易かつ迅速になりました。

さらに、スキーマが確定された段階、すなわち開発サイクルのかなり早いステージで自動化スクリプトの作成を開始できました。この早期開始がテスト実行の高速化と全体的な効率の向上に貢献しました。

自動化カバレッジの改善

これらの変更により、自動化カバレッジも大幅に向上しました。以前はUIベースおよびエンドツーエンドのテストケースに大きく依存していましたが、バックエンドテストへとフォーカスした結果、目覚ましい進展が見られました。いくつかのプロジェクトでは、バックエンドAPIの自動化カバレッジを100%達成し、すべてのAPIのテストケースを作成できました。これにより、より迅速で信頼性が高く、包括的なテストが保証できるようになりました。

テスト初期段階でのバグ発見数の増加

プロジェクト開発の初期段階において、バグを迅速に検出し、修正できるという大きな利点があることを確認しました。また、開発とテストが段階的に、かつ並行して進められたことにより、ライフサイクルの早い段階で重大な問題を特定し、修正することが可能となりました。そして、この能動的なアプローチにより、プロダクト全体の品質が向上し、リリース直前の緊急対応を減らすことができました。

バグ発生傾向：シフトレフト vs. 従来型アジャイル

以下のグラフは、「シフトレフト」と「従来型アジャイル（またはウォーターフォール的）」という2つの開発手法における、バグの発生パターンを比較したものです。

グラフの解釈

このグラフは、バグがいつ、どのように発見されるかにおける重要な違いを示しています：

• シフトレフトアプローチ：バグの発生は開発サイクル全体を通じて一貫しており、均等に分散されています。

• 従来型アジャイルアプローチ：バグの発生は特にスプリントの終盤で急増する傾向があります。

この可視化は、シフトレフトテストによって、よりスムーズなワークフローと問題の早期発見が可能になることを示しています。

シフトレフトアプローチの場合

• バグの一貫した検出：バグは開発サイクル全体を通じて継続的かつ安定的に特定・報告されるため、開発の進行がよりスムーズになります。

• 段階的なテスト：各機能が小さな単位でQAに引き渡されることで、バグも管理しやすい単位で報告され、原因の特定と修正が容易になります。

• ボトルネックの削減：開発初期からテストを実施することで、スプリント終盤に問題が集中することを防ぎます。

従来のウォーターフォールアプローチの場合

• 大量バグ検知の遅延：スプリントの終盤に大量の成果物がQAに渡されるため、バグ報告が急増する傾向があります。

• テストのボトルネック：短期間にテストを詰め込むことで、QAチームの負荷が増大します。

• 拙速な修正とストレスの増加：限られた時間の中でバグ修正が急がれるため、問題の見落としやリグレッションのリスクが高まります。

開発チームとQAチーム間の連携強化

QAと開発チーム間の日次ミーティングにより、連携の頻度が増し、コミュニケーションの遅れが減りました。

開発チームはQAチームが何をしているのか、QAの活動について把握していました。この連携の強化は、チームと経営陣の双方の信頼を高めました。これにより、開発側は以下の点について適切な認識を持つことができました。

• QAチームがカバーしているテストケースの種類

• 自動化カバレッジ率の改善

• 全体的なテストの進捗状況

チームにシフトレフトテストを導入するには

この戦略的な転換により、PayPayのQAチームのアプローチは大きく変革されました。

チームは従来型のテスト手法に限定されることなく、品質保証を強化するために最新のツールや技術を積極的に取り入れるようになっています。

PayPayでは、マニュアルテストと自動化テストの担当者を区別していません。すべてのQAエンジニアが、プロジェクトのエンドツーエンドの品質保証に責任を持ち、マニュアルテスト、自動化、UI検証、全体的なテスト戦略の策定まで幅広く担当します。

このアプローチを支えるため、PayPayおよびPayPay Indiaでは、自動化スキルが高く、QAプロセスに関する深い理解を持つ多才なQAエンジニアの採用に注力しており、開発の全フェーズにおける包括的かつ効率的なテストを実現しています。

チームにシフトレフトテストを導入するための主要な戦略は以下の通りです。

1. QAを早い段階から巻き込む

• 潜在的なリスクを早期に特定するために、要件定義の議論にQAを含めることが最初のステップです

• HLD（上位レベル設計）およびLLD（下位レベル設計）の議論にQAチームを参加させ、QAが変更内容を深く理解し、並行してテスト計画とテストケースの作成を開始できるようにします

• 開発が始まる前に受け入れ基準を定義します

2. テスト駆動開発（TDD）と振る舞い駆動開発（BDD）を採用する

• TDDでは、実際のコードを書く前にテストを作成するため、QAはモックを使用して並行してテストデータ生成の作業を開始できます

• BDDでは、テストが簡単な英語（Gherkin）で書かれるため、コラボレーションが良くなり、QAはそれらのテストを開発者やプロダクトマネージャーと共有してレビューを受けることができます

3. 機能テストと結合テストを自動化する

• PostmanやRestAssuredなどのツールを使用してAPIテストを実装します

• Selenium、Cypress、Playwrightを使用してUIテストを自動化します

4. CI/CDパイプラインに継続的テストを統合する

• Jenkins、GitHub Actions、GitLab CI/CDを使用してテストを自動的に実行します

• コードの変更がマージされる前に必ずテストするようにします

今後のロードマップ

🔄 オンボーディングと導入

• シフトレフトアプローチを導入していないチームを特定

• これらのチームに対し、すべてのテストフェーズ（フロントエンド、バックエンド、統合、パフォーマンス）におけるシフトレフトの実践について、オンボーディングとトレーニングを実施

• チームと協力し、シフトレフトを開発ワークフローに統合

🔍 ギャップ分析と改善

• 欠陥検出の遅延やその他の問題につながる現在のプロセスのギャップを分析

• 特定されたギャップを解消するためのソリューションを実装し、開発サイクルへQAを早期に関与させる

• テスト計画、コードレビュー、早期段階での検証を強化することにより、開発後の問題を削減

🚀 包括的なシフトレフト導入

• テストカバレッジを拡大し、初期段階からすべての側面（フロントエンド、バックエンド、API、セキュリティ、パフォーマンス）を含める

• すべてのチームにおけるシフトレフト完全導入のためのマイルストーンを設定し、進捗を追跡

• ベストプラクティスと成功事例を広めるための知識共有セッションを実施

結論

シフトレフトテストは一つの選択肢ではなく、高品質で迅速なソフトウェア提供のために不可欠です。テストを開発サイクルの早い段階に移行させることで、チームはコストを削減し、連携を改善し、プロダクト全体の品質を向上させることができます。

主なポイント

✔ 早期にテストを開始する – 要件の議論にQAを含める

✔ テストを自動化する – 単体テスト、統合テスト、UIテストはCI/CDの一部とする

✔ TDDとBDDを活用する – 開発者がまずテストを書くことがオススメ

シフトレフトの導入は、単にバグを早期に発見することだけではありません。高品質の製品をより迅速に提供し、コラボレーションを促進することでもあります。今日から始めて、アップデートしましょう！

参考サイト

https://www.researchgate.net/figure/BM-System-Science-Institute-Relative-Cost-of-Fixing-Defects_fig1_255965523

https://deepsource.com/blog/exponential-cost-of-fixing-bugs

留意事項

上記のデータは1つのプロジェクトのみを対象としており、当社はシフトレフトアプローチを導入している他のプロジェクトからも追加データを積極的に収集しています。