シフトレフトテスト[ 1 ]は、ソフトウェアテストおよびシステムテストのアプローチであり、ライフサイクルの早い段階(つまり、プロジェクトのタイムライン上で左に移動)でテストを実行します。これは、「早期に、そして頻繁にテストする」という格言の前半部分です。[ 2 ] 2001年にラリー・スミスによって提唱されました。[ 3 ] [ 4 ]
シフトレフトテストは、テストの遅延によって引き起こされる以下の種類の弊害を防ぐことを目的としています。
テストをライフサイクルの早い段階(つまり、従来のVモデルでいうと左方向)にシフトさせる基本的な方法は4つあります。これらは、従来型のシフトレフトテスト[ 5 ]、インクリメンタルシフトレフトテスト、アジャイル/ DevOpsシフトレフトテスト[ 6 ] [ 7 ] 、モデルベースのシフトレフトテスト[ 8 ]と呼ばれます。
次の図に示すように、従来のシフトレフトでは、テストの重点を古典的なVモデルの右側の下の方(つまり少し左)に移動させます。従来のシフトレフトでは、受け入れテストやシステムレベルのテスト(例えば、記録再生ツールを使用したGUIテスト[ 9 ])に重点を置く代わりに、ユニットテストや統合テスト(例えば、APIテストや最新のテストツールの使用)に重点を置きます。従来のシフトレフトテストへの移行はほぼ完了しています。
次の図に示すように、大規模で複雑なソフトウェア依存システムを開発する多くのプロジェクトでは、開発を少数の増分(V)に分割し、それぞれの増分期間を短くしています。赤い破線の矢印で示されている左シフトは、単一の大きなウォーターフォールVモデルのテストタイプ(灰色で表示)の一部が左にシフトされ、より小さな増分Vモデルの対応するテストタイプの増分となるために発生します。各増分が顧客と運用への納品でもある場合、増分左シフトテストでは、開発テストと運用テストの両方が左にシフトされます。増分左シフトテストは、大規模で複雑なシステム、特に大量のハードウェアを組み込んだシステムを開発する際によく用いられます。従来の左シフトと同様に、増分左シフトへの移行もほぼ完了しています。
次の図に示すように、アジャイルおよびDevOpsプロジェクトでは、シフトレフトテストの前の2つの例のように1つまたは少数のVの代わりに、多数の短い期間のV(スプリント)があります。これらの小さなVは、1つ以上の初期スプリントを使用して基本的な要件とアーキテクチャをブロックアウトする場合、またはテストファーストおよびテスト駆動開発(TDD)が実行されている場合にも変更されます。シフトレフトが発生するのは、これらの小さなVの最も初期の右側のテストの種類が、それらが置き換えるより大きなVの右側の対応するテストの種類よりも左側にあるためです。次の図はアジャイルとDevOpsで非常によく似ていますが、アジャイルテストは通常、開発テストに限定され、システムが運用開始された後に行われる運用テストは含まれません。アジャイル/DevOpsシフトレフトテストへの移行は現在人気があり、進行中です。
これまでのテスト手法はすべて、開発サイクルの早い段階でのテストに重点を置いていた。しかし、いずれもソフトウェアが完成した後にテストを行い、実装上の欠陥のみを明らかにすることを目的としていた。
モデルベーステストは、要件、アーキテクチャ、設計モデルをテストすることで、テストをV字型の左側に移動させます。この変化により、ソフトウェアがV字型の右側で利用可能になるまで長時間(従来型テスト)、中時間(インクリメンタルテスト)、または短時間(アジャイル/DevOps)待つ必要がなくなり、ほぼ即座にテストを開始できます。この傾向はまだ始まったばかりです。