mcpField
S
shift-left-testing

shift-left-testing

github.com/petrkindlmannテスト・品質2221.1k 回インストール6 日前に更新
リポジトリ

shift-left-testing について

開発・QAチーム向けに、要件、開発、プルリクエストの段階へ品質確認を前倒しする方法を案内します。QAとの協業、TDDの判断、PRチェックリスト、成熟度モデルを扱います。

主な機能

  1. 01スプリント計画へのQA参加
  2. 02Three Amigosによる要件整理
  3. 03共同でのテスト設計
  4. 04TDDとテスト後実施の選択
  5. 05PRのテスト品質チェックリスト
  6. 06チーム成熟度と次の段階の評価

活用シーン

  1. 01開発前に受け入れ基準の不足を発見
  2. 02バグ修正前に失敗するテストを作成
  3. 03PRやAI生成コードのテスト品質を確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/petrkindlmann/qa-skills --skill shift-left-testing

インストール後、Claude Code で/shift-left-testingを入力して読み込まれたか確認します。

同梱ファイルreferences/tdd-examples.mdreferences/templates.md

詳細

不具合の修正がより安く、早く、簡単な開発ライフサイクルの早い段階で、品質検証を行います。リファインメントで見つかった検証ルールの不足は、5分間の話し合いで解決できます。同じバグが本番環境で見つかれば、インシデント対応、ホットフィックス、振り返りが必要になります。このスキルでは、ストーリーのリファインメントから PR のマージまで、すべてのフェーズに品質を組み込むためのプラクティス、パターン、文化的な変化に加え、次に取るべき具体的なステップを見つけるための成熟度モデルを扱います。

クイックルート

状況移動先
開発が「完了」してから初めて QA が機能を見る開発／QA の連携 → スプリント計画での QA 参加
開発前に要件について話し合いたい開発／QA の連携 → スリーアミーゴセッション
この作業に TDD を適用するか判断したいTDD の進め方 → TDD とテスト先行後実装の使い分け
テストの品質について PR をレビューしたいPR レビューチェックリスト
AI が生成した／AI を使用する PR をレビューしたいPR レビューチェックリスト → 変更が AI 生成の場合
「チームの現状と次のステップを知りたい」シフトレフト成熟度モデル

発見のための質問

まず .agents/qa-project-context.md を確認してください。存在する場合はその内容（チーム構成、開発／QA のワークフロー、スプリント構成、品質目標）を利用し、そこに回答がある質問は省略します。

現在の開発／QA ワークフロー

  1. QA は機能をいつ初めて確認しますか？ PR が作成された後ですか？ ステージング環境へのマージ後ですか？ バグが発生してからですか？ 回答から、現在の品質活動がどれほど後工程に偏っているかがわかります。

  2. 誰が、いつテストを書きますか？ 開発者だけですか？ 開発が「完了」してから QA だけが書きますか？ 両方が書きますが、タイミングは別々ですか？ 現在の責任分担を理解することは、変更を始める前に不可欠です。

  3. 要件はどのように伝達されますか？ 文書化された仕様ですか？ 口頭での引き継ぎですか？ 受け入れ基準のない Figma リンクですか？ 曖昧な要件は、シフトレフトで防げる不具合の最大の原因です。

  4. TDD に関心はありますか？ チームで以前に試したことはありますか？ 定着しましたか、それとも頓挫しましたか？ 過去の取り組みを理解すれば、失敗したアプローチを繰り返さずに済みます。

  5. PR レビュープロセスはどのようなものですか？ 誰がレビューしますか？ テスト容易性はレビュー基準に含まれていますか？ マージ前にテストが必須ですか？ PR レビューは、品質チェックを導入するうえで最も負担の少ない機会です。

  6. チームの完了の定義（DoD）は何ですか？ 明文化されていますか、それとも暗黙のものですか？ テストは含まれていますか？ 強制されていますか、それとも努力目標ですか？ DoD は、「進行中」と「完了」を分ける取り決めです。

  7. QA はスプリント計画にどのように参加しますか？ まったく参加しませんか？ 見積もりについて意見を求められますか？ ストーリーのリファインメントに積極的に参加しますか？ スプリント計画への参加状況によって、QA の視点がサイクルのどれだけ早い段階で入るかが決まります。

基本原則

1. 品質は全員の責任です

品質は、開発後に QA チームが実施する工程ではありません。ワークフロー全体に備わる特性です。プロダクトマネージャーはテスト可能な要件を書き、開発者はコードと並行してテストを書き、コードレビュー担当者はテスト容易性を確認し、QA エンジニアはテスト戦略を設計して自動化で検出できない問題を見つけます。品質が全員の責任であれば、不具合は最初に見つけた人が検出できます。

2. 早期検出ほど修正コストは低くなります（定性的な傾向）

ストーリーのリファインメント中に見つかった検証ルールの不足は、5分間の話し合いで解決できます。同じ不具合が本番環境で見つかれば、インシデント対応、ホットフィックス、振り返りが必要になり、ユーザーの信頼も損なわれます。不具合の修正コストは、検出が後工程になるほど大きく上昇します。リファインメント < 設計 < 開発 < QA < ステージング < 本番環境、という順です。この傾向自体には根拠がありますが、正確な倍率には根拠がありません。 広く引用されている「1x → 100x」の表は、公開された方法論がない、日付も出典も不明な IBM Systems Science Institute の研修用チャートに由来します。そのため、正確な数値は実測値ではなく、あくまで説明のための例として扱ってください。作り上げた数値ではなく、上記の具体的なコストの話を中心に伝えます。シフトレフトのプラクティスは、QA、ステージング、本番環境に至る前に、コストの低い前工程、つまりリファインメントから開発までの段階で不具合を検出することを目指します。

3. QAはゲートではなく、プロセスに組み込まれています

従来のQAは、開発の最後にゲートとして機能します。コードはテストのために「壁の向こうへ投げ込まれ」ます。シフトレフトでは、QAをプロセス全体に組み込みます。QAはストーリーの詳細化に貢献し、開発者とテスト設計を共同で行い、テスト容易性の観点からPRをレビューし、継続的なテストを通じて早期に検証します。ゲートモデルはボトルネックと対立的な関係を生みます。組み込みモデルは、協力と責任の共有を促します。

4. テスト容易性は設計上の考慮事項です

テストが難しいコードは、たいてい保守やデバッグも難しく、欠陥を含む可能性も高くなります。テスト容易性は、パフォーマンス、セキュリティ、ユーザビリティと並ぶ、設計における最優先の制約とすべきです。コードを1行も書く前の設計段階で、開発者が「これをどうテストするのか」と問いかけると、よりクリーンで、モジュール性と信頼性の高いアーキテクチャにつながります。

5. 小さく始めて価値を実証し、その後に拡大します

シフトレフトのプラクティスをすべて同時に導入すると、チームに過度な負担がかかります。まず1つのプラクティス（通常はPRレビューのチェックリストかThree Amigos）を選び、データ（流出するバグの減少、PRサイクルの短縮）でその価値を実証します。その成功を次のプラクティス導入の根拠にしましょう。文化の変化は、実証された成功を1つずつ積み重ねることで起こります。

開発／QAのペアリングパターン

スプリント計画におけるQA

実施内容： QAエンジニアがスプリント計画に参加し、ストーリーの詳細化にも積極的に加わります。エッジケースについて明確化を求め、受け入れ基準の不足を特定し、開発開始前にリスク領域を指摘します。

計画中の具体的なアクション：

  1. 各ストーリーの受け入れ基準がテスト可能か確認します。 すべての受け入れ基準は検証可能であるべきです。「ユーザーがテーブルを並べ替えられる」はテスト可能ですが、「テーブルが使いやすい」はテストできません。
  2. エッジケースと異常系のシナリオを特定します。 データが空の場合はどうなりますか？最大長の入力はどうなりますか？同時に複数のユーザーが操作する場合はどうなりますか？処理中にネットワーク障害が発生した場合はどうなりますか？
  3. 統合上のリスクを指摘します。 このストーリーはサードパーティのAPIに触れますか？データベースのスキーマを変更しますか？既存のテストデータに影響しますか？
  4. QAの作業量を見積もります。 自動化にかかる時間、探索的テストの時間、環境のセットアップを見積もり、スプリントの作業容量に含めます。
  5. ストーリーごとにテストアプローチを定めます。 ビジネスロジックにはユニットテスト、APIの変更には統合テスト、ユーザー向けのフローにはE2Eテストを使用します。

テンプレート：各ストーリーに対するQAの質問

Story: [PROJ-1234] Add coupon code to checkout
───────────────────────────────────────────────
QA questions before development starts:
1. What happens if the coupon is expired?
2. What happens if the coupon is already used (single-use)?
3. Can multiple coupons be stacked?
4. What error message does the user see for invalid codes?
5. Does the discount update the total in real-time or on submit?
6. Is there a rate limit on coupon validation attempts?

Test approach:
- Unit: coupon validation logic, discount calculation, expiry check
- Integration: coupon API endpoint, database state after redemption
- E2E: apply coupon in checkout flow, verify discount on confirmation
- Exploratory: edge cases with currency rounding, max discount limits
Three Amigosセッション

開発開始前に、3つの視点から構成される、構造化された15～30分の対話を行います。

3つの視点：

  • プロダクト／ビジネス： ユーザーに必要なものは何ですか？なぜ重要ですか？
  • 開発： どのように構築しますか？技術的な制約は何ですか？
  • QA／テスト： どのように検証しますか？どのような問題が起こり得ますか？

任意の4人目のAmigo（AI参加者）： コーディングエージェントは、セッション中に受け入れ基準からエッジケースや反例となるシナリオを生成できます。AIの出力は、検証するチェックリストとして扱い、判断として扱わないでください。基準に対する責任は、引き続き人間が担います。

セッションの進め方（最大30分）：

  1. プロダクト担当者がストーリーを説明する（5分）-- ユーザーのニーズ、受け入れ基準
  2. 開発担当者が明確化のための質問をする（5分）-- 実現可能性、依存関係
  3. QA担当者がテストに関する質問をする（5分）-- エッジケース、エラー状態、テスト容易性
  4. グループで不足点を洗い出す（10分）-- 不足している基準を追加し、前提を明示する
  5. 合意して次のステップを決める（5分）-- ストーリーを更新し、リスクを記録し、テストアプローチに合意する

使用する場合： リスクスコアがMedium以上のストーリー、決済／認証／データ整合性に関わるもの、要件が曖昧なストーリー、チーム横断のストーリー。

省略する場合： 再現手順が明確な単純なバグ修正、コピーやテキストのみの変更、動作の変更を伴わない依存関係の更新。

テストファースト設計のQAペアリング

実装前に、QAと開発者が協力してテストケースを作成します。これは本格的なTDDではなく、テストの考え方を共同で適用する方法です。

進め方：

  1. 開発者とQAが一緒に（または画面を共有して）20～30分取り組みます
  2. QAがテストする予定のシナリオを説明します
  3. 開発者がテストのシグネチャ（関数名、入力、期待される出力）を記述します
  4. どのテストがユニット、統合、E2Eに該当するかを一緒に確認します
  5. 開発者が、これらのテストを目標に機能を実装します

ペアリングセッションでの成果物の例： 実装前に作成した、ユニット、統合、E2Eの各レベルにまたがる、合意済みのテストシグネチャ一式です。クーポン機能のペアリング成果物の全体については、references/tdd-examples.mdを参照してください。

QAによるPRレビュー

QAエンジニアは、他の開発者によるコードレビューを補完する形で、テストのしやすさとテストの品質に重点を置いてプルリクエストをレビューします。

QAによるPRレビューに初めて取り組むチーム向けの始め方：

  1. まずはリスクの高いPRのみを、QAレビュアー1名で確認します。 初日からすべてのPRをレビューしようとしないでください。
  2. レビューは15分以内にします。 QAはテストの品質を確認するのであり、ビジネスロジックを再レビューするのではありません。
  3. 以下のPRレビュー用チェックリストを使います。 具体的で客観的な基準が示されているため、主観的な判断は必要ありません。
  4. コメントは要求ではなく提案として残します。 「テストが不足しています」ではなく、「空の状態をテストに追加することをご検討ください」のように伝えます。
  5. 効果を記録します。 QAレビューで問題を検出した場合は記録します。2～4週間後、その件数をチームに共有してROIを示します。

TDDの進め方

レッド・グリーン・リファクター

TDDは、厳密な3ステップのサイクルに従います。各ステップには明確な目的と終了条件があります。

┌──────────────────────────────────────────────────────┐
│  RED: Write a failing test                           │
│  - Test describes the desired behavior               │
│  - Test MUST fail (if it passes, it tests nothing)   │
│  - Write the minimum test to specify one behavior    │
│                                                      │
│  GREEN: Make the test pass                           │
│  - Write the minimum code to pass the test           │
│  - No extra features, no premature optimization      │
│  - It is OK if the code is ugly                      │
│                                                      │
│  REFACTOR: Clean up                                  │
│  - Improve code structure without changing behavior  │
│  - All tests still pass after refactoring            │
│  - Remove duplication, improve naming, simplify      │
└──────────────────────────────────────────────────────┘

例：パスワード強度バリデーターのTDD — 最初に失敗するテストを書き、最小限のコードでテストを通し、その後、動作を変えずにルール配列へリファクタリングします。レッド・グリーン・リファクターの全手順については、references/tdd-examples.mdを参照してください。

TDDとテスト後のどちらを選ぶか：判断ガイド

TDDが常に適切とは限りません。このガイドを使って判断してください。

シナリオアプローチ理由
純粋なビジネスロジック（バリデーター、計算機、変換器）TDD入出力が明確で、フィードバックが速く、テストが動作を説明します
再現方法がわかっているバグ修正TDD最初に失敗するテストを書くことで、修正が機能する証拠になります
契約が明確なAPIエンドポイントTDDリクエスト／レスポンスが自然なテスト境界になります
探索的なUIプロトタイピングテスト後設計が安定していないため、テストを何度も書き直すことになります
サードパーティとの統合テスト後まずAPIの動作を理解する必要があります
複雑なデータ移行フィクスチャを使ったテスト後まずサンプルデータを用意し、その後に変換をテストします
パフォーマンス最適化ベンチマークを使ったテスト後改善をテストする前にベースラインが必要です
AIが生成した実装TDD（テストファースト）LLMは、テストに通りそうなコードを喜んで生成します。失敗するテストが、エージェントの満たすべき仕様になります。AIの出力を確認するうえで、最も効果の高いチェックです。
バグに対するTDD（判断基準）

バグ修正はすべて、バグを再現する失敗テストから始める必要があります。この方法により、次の3つが保証されます。

  1. バグを理解できます。 失敗するテストを書けない場合、そのバグを理解できていません。
  2. 修正が実際に機能します。 修正を適用すると、テストが成功します。
  3. バグが再発しません。 テストが回帰防止策としてテストスイートに残ります。

失敗するテストを先に書く具体例（JPYの小数点以下を持たない通貨における丸め誤差のバグ）については、references/tdd-examples.mdを参照してください。

TDD を学ぶチーム向けのカタ演習

TDD の筋肉記憶を身につけるための短い演習（30～60 分）：

カタ難易度主な学び
FizzBuzz初級基本的な Red-Green-Refactor サイクル
String Calculator初級段階的な複雑さ、エッジケース
Roman Numerals中級パターン認識、リファクタリング
Bowling Game中級状態管理、複雑なルール
Gilded Rose上級テストハーネスを使ったレガシーコードのリファクタリング

形式： ペアプログラミングを 45 分間行い、5 分ごとにドライバーを交代します。15 分間の振り返りでは、難しかったこと、自然に感じたこと、別のやり方ができたかを話し合います。

PR レビューチェックリスト：QA の視点

テストの品質とテスト容易性を確認する際に、このチェックリストを使用してください。すべての項目がすべての PR に当てはまるわけではありません。変更範囲に応じて判断してください。

テストが存在し、意味のある内容になっている
  • コードの変更にテストが伴っています。 新機能なら新しいテスト、バグ修正なら回帰テスト、リファクタリングなら既存のテストが引き続きパスすること（できればテストも改善されていること）が必要です。動作変更を含むのにテストがない PR には、明確な理由が必要です。
  • 正常系とエッジケースの両方がカバーされています。 最低限、有効な入力、無効な入力、空または null の入力、境界値を確認します。ユーザー向け機能では、エラー状態、読み込み状態、空の状態も確認します。
  • テストは実装ではなく動作を説明しています。 テスト名は仕様として読めるものにします。rejects expired coupon with clear error message のようにし、test coupon validator function line 42 のような名前は避けます。
コードがテスト可能である
  • 関数の入力と出力が明確です。 純粋関数は簡単にテストできます。副作用のある関数では、副作用を分離する必要があります（依存性注入、ラッパー関数など）。
  • 依存関係を注入できます。 データベースクライアント、HTTP クライアント、時計、乱数生成器は、ビジネスロジック内で直接インポートするのではなく、パラメーターとして渡すか、注入する必要があります。
  • ハードコードされたマジック値がありません。 定数には名前が付けられ、設定可能になっています。本番コードを変更せずに、テストから値を上書きできます。
テストの品質
  • セレクターに安定した方法を使用しています。 E2E テストでは、CSS クラスや XPath ではなく、data-testid、getByRole、getByLabel を使用します。test-reliability のセレクター安定性の評価を参照してください。
  • アサーションが具体的です。 expect(result).toEqual({ status: 'expired', code: 'COUPON_EXPIRED' }) のようにし、expect(result).toBeTruthy() のようなアサーションは避けます。
  • テストデータが決定的です。 明示的に制御されていない現在の日付、ランダム値、自動インクリメント ID に依存しません。ファクトリーまたはフィクスチャを使用します。
  • テストが後片付けを行います。 作成したレコードを削除し、変更した状態を復元します。テスト間に汚染を残しません。
  • テスト名でシナリオが説明されています。 コードに詳しくない人でも、テスト名だけで何をテストしているか理解できるようにします。
  • カバレッジだけを目的としたテストがありません。 意味のあるアサーションなしにコードを実行するテストは、安全性を高めずにカバレッジを押し上げます。
変更が AI によって生成された、または AI を使用する場合

PR に AI エージェントが作成したコードが含まれる場合、または AI を活用した機能を導入する場合は、以下の追加チェックを適用してください。

  • AI の生成元を明示。 PR の説明に、エージェント名、モデル名、生成した内容を記載します（レビュー担当者が適切なレベルの精査を行えるようにするためです）。
  • テストは先に作成するか、人間が作成。 AI が生成した実装と AI が生成したテストを組み合わせると、閉じたループになります。テストと実装の組み合わせの少なくとも一方は、人間が作成するか、批判的にレビューする必要があります（上記の TDD 意思決定ガイドの行を参照）。
  • プロンプトとモデルのバージョンを固定。 AI を使用する機能（LLM 呼び出し、プロンプトテンプレート）では、プロンプトのバージョンとモデル ID をフラグベースの設定ストア（LaunchDarkly AI Configs（GA 2025）または同等のもの）に保存し、場当たり的な文字列として埋め込んで、時間とともにずれが生じる状態にしないでください。PR ではプロンプトをインラインで貼り付けるのではなく、設定キーを参照してください。
  • 実行時のキルスイッチを接続。 AI 機能は、再デプロイせずに無効化できるフィーチャーフラグの背後でリリースしてください。シフトレフトの予防とシフトライトの封じ込めを組み合わせます。
  • プロンプト評価テストがある。 代表的な入力に対するプロンプトの動作を検証する回帰テストを少なくとも 1 つ用意してください（ai-system-testing を参照）。
  • 架空の API やインポートがない。 インポートされたすべてのシンボルが実在することをレビュー担当者が確認します。LLM はもっともらしい API をでっち上げることがあります。

完了の定義テンプレート

完了の定義（DoD）は、「完了」が何を意味するかについてチームで共有する合意事項です。ストーリーがボード上で「完了」に移る前に、すべてのストーリーに適用されます。

推奨する品質ゲート付き DoD

完全な DoD では、チェック項目を「コード完了」「テスト済み」「品質ゲート合格」「ドキュメント」「デプロイ準備完了」に分類します。「テスト済み」には、ビジネスロジックの単体テスト、API／サービスの変更に対する統合テスト、ユーザー向けの重要な経路に対する E2E テスト、エッジケースとエラー状態の網羅、そして中／高リスクの変更に対する手動の探索的テストの完了が必要です。「品質ゲート」には、CI パイプラインの成功、新たな lint／型エラーがないこと、コードカバレッジがベースラインを下回らないこと（根拠なく設定した絶対しきい値ではなく、ベースライン値）が必要です。コピーして使える完全なチェックリストは references/templates.md を参照してください。

DoD の適用

DoD は適用されて初めて効果を発揮します。適用方法は 3 つあります。

  1. CI の自動ゲート。 テストに合格し、カバレッジが低下せず、lint が通る必要があります。チームリードの承認なしにこれらを回避することはできません。
  2. PR テンプレートのチェックリスト。 PR テンプレートに DoD をチェックリストとして含めます。レビュー担当者は各項目にチェックが入っていることを確認します。
  3. スプリントレビューでの検証。 スプリントレビューでは、DoD を満たした場合にのみストーリーを受け入れます。「動くけれど、テストはまだ書いていない」は、完了ではありません。

シフトレフト成熟度モデル

現在チームがどの段階にあるかを評価し、改善に向けた具体的な次のステップを特定します。

レベル 1：事後対応型

症状：

  • QA は開発完了後にのみテストを行う
  • バグはステージング環境または本番環境で見つかる
  • 自動テストがない、またはカバレッジが最低限しかない
  • 要件が曖昧で、QA がテスト中に不足に気づく
  • 「QA フェーズ」がスプリント末尾の独立した期間になっている

次のステップ： スプリント計画に QA を加えます。まず、開発開始前に各ストーリーについて QA が確認の質問をすることから始めます。測定方法：計画時に見つかった要件の不足と、テスト時に見つかった不足の数を比較します。

レベル 2：ゲート

症状：

  • QA は PR をレビューするが、設計には参加しない
  • 自動テストはあるが、機能の完成後に作成される
  • DoD はあるが、テスト項目が省略されることが多い
  • QA は協力者ではなく、チェックポイントになっている
  • テストを後回しにするため、バグの発見が遅れ、手戻りが多い

次のステップ： 高リスクのストーリーに Three Amigos を導入します。開発開始前に QA、開発担当者、プロダクト担当者が要件、エッジケース、テスト方針について話し合います。測定方法：QA テスト中に見つかるバグの減少（上流の品質が向上するにつれて減るはずです）。

レベル 3：組み込み

症状： QA がスプリント計画とストーリーの詳細化に参加します。開発者は開発中に単体テストと統合テストを作成します。PR レビューにはテスト容易性の確認が含まれます。QA と開発者がペアでテストケースを設計します。DoD が自動品質ゲートによって適用されます。

次のステップ： バグ修正にテストファーストの実践を導入します（すべてのバグ修正は失敗するテストから始めます）。純粋なビジネスロジックに TDD を拡大します。測定項目：リグレッション率（ゼロに近づくことが目標です）。

レベル 4：協働

症状： 中〜高リスクのストーリーでは Three Amigos が標準です。開発者はビジネスロジックとバグ修正に TDD を実践します。QA は探索的テスト、戦略、リスク分析に注力します。品質メトリクスを追跡し、定期的にレビューします。品質は部門横断的に所有します。

次のステップ： アーキテクチャと設計のレビューにシフトレフトを導入します。QA は実装開始前に、システム設計ドキュメントのテスト容易性をレビューします。測定項目：欠陥流出率（一貫して 5% 未満）。

レベル 5：予防

症状： 品質がすべての段階に組み込まれています。欠陥流出率は一貫して 3% 未満です。QA エンジニアは戦略、コーチング、システム全体の改善に注力します。本番環境の問題はまれで、発生した場合は根本原因分析を行います。チームは、早期に品質を確保する取り組みなしでは働けないと感じています。

このレベルの維持： 四半期ごとに成熟度を評価します。新しいチームメンバーには、初日から品質の実践方法をオンボーディングします。振り返りには品質メトリクスを含めます。

自己評価ワークシート

8 つの実践項目（計画への QA の参加、Three Amigos、PR レビュー、開発中のテスト、バグ修正での失敗テストファースト、ビジネスロジックの TDD、DoD の適用、メトリクスのレビュー）を「まったくない／ときどき／たいてい／いつも」の尺度で評価し、チームがレベル 1〜5 のどこに位置するかを判定します。採点基準付きの印刷可能なワークシートについては、references/templates.md を参照してください。

アンチパターン

QA の人員削減を「シフトレフト」と呼ぶ

「開発者がすべてのテストを書く」ことをシフトレフトと言い換え、QA の役割をなくす正当化に利用します。シフトレフトで変わるのは品質を確保するタイミングであり、担い手ではありません。QA エンジニアは、テストの視点、リスク分析のスキル、探索的テストの能力をもたらしますが、開発者は通常、こうした能力を身につけていません。QA をなくし、開発者に「もっとテストするように」と伝えても、コスト削減ではなく、見落としにつながります。

実質を伴わないセレモニー

難しい質問を誰も投げかけない、チェック項目をこなすだけの Three Amigos ミーティングを実施します。セッションの結果、受け入れ条件が少なくとも 1 つ変更されるか、新たなエッジケースが少なくとも 1 つ見つからないのであれば、実質的な議論とは言えません。「Three Amigos で見つかったギャップ」をメトリクスとして追跡します。

常にすべてを TDD で行う

設計がまだ流動的な UI のプロトタイピング、探索的なスパイク、実験的な機能にも TDD を強制します。TDD は、期待される動作が明確なときに最も効果を発揮します。不確実な領域では、まずスパイクを行い、その後、明らかになった設計に沿ってテストを書きます。上記の判断ガイドを使用してください。

チームの合意を得ずに品質ゲートを設ける

その理由を説明したり、しきい値の設定にチームを参加させたりせずに、厳格な品質ゲート（カバレッジのしきい値、必須の QA レビュー）を課します。押し付けられたと感じられるゲートはチームの進行を遅らせ、回避されるようになります。共同で設定したゲートは、チームが自ら守ります。

間違ったレベルですべてをテストする

単体テストで検証すべきビジネスロジックに E2E テストを書きます。E2E 検証が必要なユーザーフローに単体テストを書きます。シフトレフトとは、単に「早くテストする」ことではなく、「できるだけ早く、適切なレベルでテストする」ことです。計算のバグには単体テストが必要であり、ブラウザーテストではありません。

成果ではなく活動を測定する

「Three Amigos のセッション開催数」ではなく、「計画時に見つかった欠陥と本番環境で見つかった欠陥」を追跡します。活動はインプットであり、成果はアウトプットです。シフトレフトの実践によって、実際に流出した欠陥や手戻りが減っているかを測定します。

検証

ゲートが実際に機能することを証明してください。まったく発動しないゲートには意味がありません。

  1. テストのない動作変更 PR がブロックされる。 テストを追加せずに動作を変更する（またはカバレッジをベースライン未満に下げる）使い捨ての PR を作成し、CI が失敗し、マージボタンが無効になることを確認します。マージできてしまうなら、そのゲートは形だけです。
  2. DoD チェックリストが PR テンプレートに表示される。 DoD チェックリストが .github/pull_request_template.md（またはお使いのプラットフォームに相当するファイル）にあり、レビュアーがすべての PR で確認できることを確かめます — test -f .github/pull_request_template.md && grep -qi "unit test" .github/pull_request_template.md。
  3. AI キルスイッチをオフに切り替えられる。 AI を利用する経路がある場合は、フラグ管理プラットフォームでその機能フラグを無効にし、再デプロイせずにその経路が停止することを確認します。

完了条件

  • 完了の定義にテスト基準（ユニットテスト、統合テスト、E2E のゲート）を追加し、リポジトリにコミットしている（例：.github/pull_request_template.md に記載されている）
  • テストカバレッジの確認を含む PR レビューチェックリストを PR テンプレートに追加し、ブランチ保護で必須にしている
  • 近日実施予定の機能について Three Amigos セッションを少なくとも 1 回実施し、見つかった不足点を記録して、チケットの受け入れ条件を更新している
  • 最初の開発者／QA ペアリングセッションを実施し、合意したテストシグネチャをリポジトリにコミットしている
  • マージ前の品質ゲート（テスト合格、カバレッジの低下なし、リンティング）が CI で有効になっており、テストのない PR が失敗することを確認している（「検証」手順 1 を参照）
  • リスクの高い、または AI を利用するコード経路ごとに機能フラグを用意し、フラグ管理プラットフォームで無効化の切り替えを確認している（「検証」手順 3 を参照）。これにより、予防（シフトレフト）と封じ込め（シフトライト）を一体として提供できます

参考ファイル（references/ 内）

  • tdd-examples.md — 開発者／QA のペアリングによるテストファースト設計、Red-Green-Refactor による password-validator の手順、および失敗するテストを先に書くバグ修正の例を含む、実行可能なコードです。
  • templates.md — 品質ゲートを含むコピーして使える完了の定義と、シフトレフトの成熟度を自己評価するワークシートです。

関連スキル

  • unit-testing -- 効果的なユニットテストを書くための詳細なパターンです。シフトレフト型開発の実践で中心となる成果物です。
  • ai-qa-review -- テストの品質とテスト容易性を対象とする PR 自動レビューで、ここで説明する QA レビューパターンを拡張します。
  • test-strategy -- シフトレフトの実践を日々の作業レベルで実現する、全体的なテストアプローチです。
  • qa-project-context -- どのシフトレフトの実践から導入するかを決める、プロジェクト固有のコンテキストです。
  • quality-postmortem -- シフトレフトが機能せずに欠陥が流出した場合、ポストモーテムによって、どの実践が欠陥を検出できたかを特定します。
  • qa-project-bootstrap -- 新しいチームメンバーのオンボーディングには、チームのシフトレフトの実践を紹介することも含まれます。

コメント

Markdown 対応