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

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

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

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

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

この欠陥の修正にはどのくらいの時間がかかりますか。タイムラインにどの程度の影響がありますか。修正により新たなバグが入り込んだりしませんか。修正プログラムが最初のものを修正している間に壊したものを修正する時間があれば、各修正が検証されることをどうやって保証するのでしょうか。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

シフト・レフトは単に自動化の問題ではありません。テストをより早く、さらに頻繁に行う別の方法は、ディスカバリーや要件収集などの最初の段階から、プロセスのすべてのステップに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テストを行うことは、シフト・レフトとシフトライトの実施のメリットを組み合わせるのに最適な方法です。