ホーム Topics シフトレフト・テスト シフトレフト・テストとは
IBMのシフトレフト・テスト・ソリューションの詳細はこちら AI関連の最新情報の購読を申し込む
シフトレフト・テストの仕組みを示す図
シフトレフト・テストとは

シフトレフト・テストとは、ソフトウェア開発において、ソフトウェア品質の向上、テスト範囲の拡大、継続的なフィードバック、および市場投入までの時間の短縮のために、テスト活動を開発プロセスの早い段階に移行することを重視するアプローチです。

予算を超過し、締め切りをすべて守れなかったソフトウェア・プロジェクトに関わったことはありますか。もちろんあるでしょう。私たちには皆そのような経験があります。実際、そんな経験がないという人は一角獣のような架空の存在であり、いるとしたら話を聞いてみたいところです。

ソフトウェア開発のキャリアの早い段階で、私は締め切りから逆算して作業することの重要性を学びました。プロジェクトを特定の日付までに完了する必要があり、テストに一定の時間がかかるという場合、その情報から逆算してプロジェクトの期限を選択できます。それで完璧だと思いませんか。

しかし現実には、そううまくはいきません。手動によるテストの時間が確保されていたので、プロジェクトの最終日のストレスはある程度軽減されましたが、それでも驚くような事態があまりにも多かったのです。

QAテストの時間を確保することは理論的には素晴らしいですが、実際には最初のバグや欠陥が特定されるとすぐに破綻してしまいます。

この欠陥の修正はどのくらい時間がかかりますか。タイムラインにどの程度影響がありますか。修正により新たなバグが入り込んだりしませんか。最初のバグの修正時から、修正のための時間内に各修正が確実に検証されるようにするにはどうすればよいでしょうか。

最終的に、QAに割り当てる適切な時間を見つけることがまったくできませんでした。必然的に、急いで行ったいくつかの修正は土壇場で統合されることになりました。私は大規模なプロジェクトのローンチ後の数週間は、カレンダーの予定をしっかりと空けておくことを学びました。そうすることで、見落とした(または入り込んだ)すべての問題をトリアージして、最後までやり遂げることができました。

結局のところ、問題となっていたのはテストに使える時間ではなく、テストのタイミングでした。もっと早い段階での、もっと頻繁なテストが必要でした。つまり、シフトレフト・テストが必要でした。

ソフトウェア開発プロセスを左から右に流れるタイムラインと考えると、「シフトレフト・テスト」が何を意味するかは説明せずともおわかりいただけると思います。それは簡単に言うと、初期の段階でテストを行い、テスト担当者、開発者、利害関係者を含むチーム・メンバーをテスト・ストラテジーに関わらせ、既存の機能と新機能の両方のテストを開発ライフサイクルでより頻繁に統合することです。

 

IBM Robotic Process AutomationのTotal Economy Impact™

IBMロボティック・プロセス・オートメーション(RPA)のコストとメリットの分析をご覧ください。

関連コンテンツ

インテリジェントな自動化に関するガイドを読む

ソフトウェア開発のVモデル

Vモデルは、ソフトウェア開発サイクルを概念化するのに便利な方法です。従来のウォーターフォール・フローを採用し、実装段階でY軸を「反転」させると、Vモデルが得られます。

開発サイクルは、おおまかな要件から始まります。それらの要件は、「V」までの連続する各ステップで絞り込まれ、最後にコード・レベルの実装に到達します。次に、最も詳細な単体テストから始めて、より抽象的なユーザー受け入れテストに向けて「V」まで作業を進め、実装を検証します。

ウォーターフォール・プロセスでは、プロジェクト全体が1つの「V」で構成されます。業界として私たちは、複雑なプロジェクトの場合、すべての妥当性検査をその最後に後回しにすることは、基本的に失敗につながることを学びました。

反復的なプロセスでは、各スプリントまたは反復を小さな「V」と考えることができます。私たちは理論的には、「より早く、より頻繁にテストする」というシフトレフトの目標を達成しました。それで問題は解決したということでしょうか。話はそう簡単ではありません。

シフトレフト・テストの種類

Vモデルに組み込まれたフィードバック・チャネルには、検証と妥当性検査という2つのラベルがあることに気づかれたかもしれません。そのどちらも重要です。

ユーザーが要件とする、解決しようとしている問題を実際に解決していることを検証する必要があります。また、実装が、ユーザーが要件とする仕様と一致していることを検証する必要もあります。

自動化されたテストは、妥当性検査と検証の両方に応用できます。BDD(Behavior Driven Design:ビヘイビア駆動設計)は、妥当性検査プロセスの一部を自動化できるCubumberなどのテクノロジーの開発につながりました。この記事では、検証のための自動化されたテストに焦点を当てます。

単体テスト

単体テストは、より大規模なアプリケーション内の特定のモジュールの機能を検証します。モジュールは単独でテストされ、他の外部プロセスとの通信はシミュレートまたはモックされます。単体テストとTDDは、シフトレフト・テストの最初の開発フェーズを表します。

統合テスト

統合テストは、サービスまたはアプリケーションの全体的な機能(副作用も含む)の検証を目的とします。このプロセスは、後で説明する理由から、アンチ・パターンです。

APIテストとコントラクト・テスト

APIテストは、単一サービスの外部エンドポイントを検証します。APIテストの範囲は統合テストの範囲に似ています。ただし、SOAまたはマイクロサービスの文脈では、APIテストを新しい単体テストと考えることができます。

UIテスト

UIテストでは、ユーザー・インターフェース層からアプリケーションの完全な機能を検証します。Seleniumなどのツールを使用すると、自動化されたUIテストを広く利用できるようになります。

単なる自動化ではない

シフトレフトは単に自動化の問題ではありません。テストをより早く、さらに頻繁に行うもう1つの方法は、ディスカバリーや要件収集などの最初の段階から、プロセスのすべてのステップにQAスペシャリストを関与させることです。テスト・エンジニアは、実装全体をより深く理解することでさらに良い取り組みができ、エンジニアたちの洞察は、アーキテクチャーをより透明でレジリエントなものにするのに役立ちます。

シフトレフト・テストの始め方

「より早く、より頻繁に」テストすると考えるときには、「継続的」という言葉が思い浮かびます。多くの(ほとんどの)ソフトウェア開発チームは、何らかの形式の継続的統合や継続的デリバリーを実践しています。継続的テストは、このDevOpsサイクルにおける重要なフィードバック・ループです。

継続的なテスト

TDDを「モノリスのシフトレフト」と考えると、継続的テストは「分散アーキテクチャーのシフトレフト」になります。

TDDでは単体テストに重点を置くことができました。継続的なテストの場合は、APIテストとコントラクト・テストに焦点を当てる必要があります。APIテストには、次のような多くのメリットがあります。

  • APIテストは、マイクロサービス・アプリケーションにエラーが入り込む最も一般的な経路の1つである、アップストリーム・サービスまたはダウンストリーム・サービスと同期していない依存関係の変更を防ぐことができます。

  • APIテストは、サービスを所有するのと同じチームが所有できます。

  • APIテストは、テストの副作用や実装の詳細による脆弱性を回避します。

理想的には、これらのAPIテストは、本番環境と本番前環境の両方に対して継続的に実行されます。コントラクト・テスト・ツールはこのプロセスの自動化に役立ちますが、それには追加のインフラストラクチャーが必要です。

継続的なAPIテストを可観測性ツールに組み込んだらどうでしょうか。Instanaの近日公開予定の合成APIテスト機能を使用すると、最小限の労力ですべての環境に対してAPIテストを継続的に実行できるようになります。

アジャイル開発におけるシフトレフト・テストのベスト・プラクティス

シフトレフトでは、テスト活動をソフトウェア開発ライフサイクルの開始時点に近づけることで、より迅速なフィードバックを可能にし、バグの修正に必要な時間と労力を削減します。アジャイル開発におけるシフトレフト・テストのベスト・プラクティスをいくつかご紹介します。

  1. 早期の関与:テスト活動は、開発プロセスのできるだけ早い段階から始める必要があります。テスト担当者は、プロジェクトの範囲、目的、ユーザーの期待を把握するために、要件収集段階から関与する必要があります。

  2. コラボレーションとコミュニケーション:開発者、テスト担当者、その他の利害関係者間の緊密なコラボレーションとコミュニケーションを促進します。毎日のスタンドアップ・ミーティング、スプリント・プランニング・セッション、定期的な振り返りを奨励して、共通の理解と整合性を確保します。

  3. テストの自動化:テストの自動化に投資することで、頻繁かつ効率的なテストを可能にします。自動化されたテストは、開発プロセスとともに作成され、継続的統合およびデプロイメント・パイプラインに組み込まれる必要があります。これにより、欠陥を早期に検出し、回帰の問題を減らし、フィードバック・サイクルを高速化できます。

  4. テスト駆動開発(TDD):開発者が実際のコードを書く前にテスト・ケースを書く、TDDの実践を奨励します。このシフトレフト・テストアプローチは、望ましい動作と期待される結果を事前に定義するのに役立ち、より堅牢でテスト可能なコードの生成につながります。

  5. 継続的統合と継続的デリバリー(CI/CD):CI/CDパイプラインを実装して、ビルド、テスト、デプロイメントのプロセスを自動化します。この実施により、各コード変更は徹底的にテストされ、迅速かつ頻繁に本番環境にデプロイされるようになり、統合の問題が発生するリスクが軽減されます。

  6. シフトレフトのセキュリティー・テスト:開発プロセスの早い段階でセキュリティー・テストを実施することを検討します。セキュリティー・コードのレビュー、静的コード分析、セキュリティーに焦点を当てたテストを実施して、脆弱性を特定し、プロアクティブに対処します。

  7. 探索的テスト:自動化されたテストと並行して、ユーザーの視点からアプリケーションを探索する探索的テストを奨励します。熟練したテスト担当者は、自動化されたテストで見逃される可能性のある潜在的なユーザビリティーの問題、エッジ・ケース、シナリオを特定できます。

  8. パフォーマンス・テスト:潜在的なボトルネックとスケーラビリティーの問題を特定するために、早期にパフォーマンス・テストを実行します。これは、アプリケーションのパフォーマンスを最適化し、必要なパフォーマンス基準を確実に満たすのに役立ちます。

  9. テスト環境とデータ:現実的なソフトウェア・テストを確実に実行するために、本番環境に近いテスト環境をプロビジョニングします。また、現実世界のシナリオをシミュレートするために、十分な代表的テスト・データが利用できることを確認します。

  10. 継続的な学習と改善:継続的な学習と改善の文化を育みます。定期的な振り返りを奨励して、テスト・プロセスを反映し、ボトルネックを特定し、シフトレフト・テストの有効性を高めるための変更を実装します。

これらのベスト・プラクティスを実施することで、アジャイル・チームはシフトレフト・テストを通じて、より優れたコラボレーション、より迅速なフィードバック、より高品質なソフトウェア製品を実現できます。

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

シフトレフト・プロセスに組み込まれた短いフィードバック・ループにより、さまざまな方法で向上を図ることができます。例えば、欠陥をより迅速に発見したり、修正をより効率的に適用したり、ある反復で学んだ教訓を次の反復に適用したりできます。

チームがどのようなプロジェクト管理手法やリリース頻度を採用しているとしても、シフトレフト・テストによる短い検証フィードバック・ループからメリットを得ることができます。

コストの削減:

欠陥が開発者のローカル・マシン上での自動化された単体テストによって見つかれば、特定と修正にかかるコストは抑えられます。しかし、欠陥が顧客対応環境にまで達してしまっていると、その修正にかかるコストは増大します。

開発者の福祉

自動化されたテストとCIを適切に実施すれば、ソフトウェア・エンジニアは、週末を前にした金曜日であっても自信を持って頻繁にデプロイできるようになります。欠陥を早く発見できれば、皆がパニックに陥ってしまう事態を減らすことができます。リリースは非常に簡単であるため、乗り切るべきいくつかのエラーを修正することも、より迅速で容易に行えるようになります。

レジリエントなアーキテクチャー

一般的に、よりアクセスしやすいソフトウェアがすべての人にとって使いやすいのと同様に、よりテストしやすいソフトウェアは推論や保守がしやすくなります。早期のテストを検討することで、懸念をより適切に分離でき、全体的なアーキテクチャーのレジリエンスを高めることができます。

全体的な品質の向上

顧客体験を向上させることが当社の究極の目標です。シフトレフトにより、エンド・ユーザーが経験する可能性のある一部のインシデントを排除し、他のインシデントの影響を軽減することができます。可観測性を使用することで、このフィードバック・ループを完了し、ソフトウェア全体の健全性を向上させることができます。

シフトレフト・テストの危険性

強力な自動化ツールを自由に使えると、コードのすべての行にあらゆる種類のテストを実施したいと思うようになるかもしれません。しかしこれは危険な道です。

副作用のテスト(そのレコードは実際にデータベースに保存されたのか)は、魅力的なアイデアです。しかし、このタイプのテストは非常に脆弱であるため、実装の詳細をテストすることはアンチ・パターンです。アプリケーションを変更するたびに変更することが必要になる可能性があります。ユーザー・インターフェースは実装の詳細でもあるため、UIのテストも同じことになります。

検証テストでは、「どのように」や「なぜ」ではなく、「何を」を重視します。理想的には、ユーザーの要件は「なぜ」を検証するように設計されています。「どのように」に答えるには、可観測性プラットフォームという形で、より強力な自動化に頼ることができます。

シフトレフトとシフトライト

シフトライト・テストとは、開発プロセスの後半に、通常は本番環境でテストを行うことです。奇怪に思えるかもしれませんが、シフトレフトとシフトライトのテストは補完的です。

シフトライト・テストにより、本番の問題を顧客より先に特定することができます。シフトレフト・テストによるフィードバック・ループが短いため、こうした本番の問題に迅速に対応し、修正することができます。

可観測性プラットフォームの一部として合成APIテストを行うことは、シフトレフトとシフトライトの実施のメリットを組み合わせるのに最適な方法です。

シフトレフト製品
IBM Instana


エンタープライズAPMの機能と可観測性を強化し、アプリケーションがどこにあってもアプリケーション・パフォーマンス管理を改善し、CI/CDパイプラインを高速化します。

IBM Instanaについて詳しく見る

シフトレフト・テストのリソース 可観測性とは

可観測性が最新の分散アプリケーションに対する詳細な可視性を提供し、問題のより迅速な自動化された特定と解決にどのように役立つかをご覧ください。

継続的テストとは何ですか?

継続的テストがソフトウェア開発の加速、コード品質の向上、コストのかかるボトルネックの回避においてどのように重要な役割を果たしているかをご覧ください。

DevOpsとは

DevOpsがソフトウェア開発チームとIT運用チームの作業を組み合わせて自動化することで、どのように高品質のソフトウェアの提供を迅速化するかをご覧ください。

合成モニタリングとは

合成モニタリングとは何か、その使用方法や課題など、合成モニタリングについて知っておくべきことを説明します。

オートメーションとは

テクノロジー、プログラム、ロボット工学、またはプロセスを応用して、どのように最小限の人的入力で成果を達成することができるかをご覧ください。

アプリケーション・パフォーマンス管理(APM)とは

アプリケーション・パフォーマンス管理により、ビジネスに影響する前にパフォーマンスの問題を予測して防止できます。

次のステップ

IBM Instanaは、あらゆるユーザーの利用に適したリアルタイムの可観測性を提供します。可観測性戦略が現在および将来の環境の動的な複雑さに対応できることを検証しながら、価値実現までの時間を短縮します。 モバイルからメインフレームまで、Instanaは250以上のテクノロジーをサポートしており、その数は増え続けています。

IBM Instanaについて詳しく見る デモを予約