シフトレフトテスト（Shift-Left Testing）

シフトレフトテストとは、品質に関する作業をより早い段階で行うことです。要件定義からリリースまでを左から右へ並べたタイムラインの「左側」で行う、という意味です。開発が終わった後にテストフェーズを設けるのではなく、テスターと開発者が要件をレビューし、受け入れ基準に合意し、コードと並行して自動テストを書き、コミットのたびにそれを実行します。要件レビューで見つかった欠陥なら会話 1 回で済みますが、同じ欠陥が本番で見つかればインシデントになります。

実践の姿

• リファインメント。 コードが 1 行もない段階で、テスターが「クーポンの有効期限が切れていたらどうなりますか？」と尋ね、その答えが受け入れ基準になります。
• 設計。 テスト容易性を最初に議論します。安定したテスト ID、データを投入するための API エンドポイント、フィーチャーフラグなどです。
• 開発。 ユニットテストや API テストは、数週間後ではなく機能と一緒に書きます。静的解析やリントはエディター上とプルリクエストで実行します。
• CI。 すべてのプルリクエストで高速なスイートを実行し、失敗すればマージをブロックします。

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

シフトライトテストは補完的な考え方で、モニタリング、カナリアリリース、フィーチャーフラグ、合成監視（synthetic checks）、A/B テストを通じて本番環境から学ぶことです。実際のトラフィックパターンやサードパーティの障害など、本番でしか表面化しない失敗もあります。成熟したチームは両方を行います。シフトレフトは、リリース後に何が起きているかの観察をやめる理由にはなりません。

よくある間違い

• 名前を変えただけで何も変えない。 テスターが相変わらず完成したビルドと締め切りを渡されているなら、何もシフトしていません。品質についての会話がコードを書く前に行われているかどうかが試金石です。
• 開発者だけにすべてのテストをやらせる。 シフトレフトはテストをチーム全体に広げるものであり、テストのスキルが不要になるわけではありません。テスターはコーチング、テスト設計、ツール構築へと役割を移すことが多いです。
• 自動化だけをシフトする。 UI テストを早めに実行するのは役立ちますが、最大の効果は通常、要件を明確にし、チェックをユニットや API のレベルに下ろすことから得られます。