はじめに
今回は、社内で実施した「テストケースの考え方・テスト駆動開発（TDD）勉強会」の内容や開催意図を紹介します。
勉強会は私が座学用のスライドと演習課題を用意し、約2時間の枠で開催しました。参加者は10名弱で、前半を座学、後半を演習に充てて質問を受けつつ双方向で進めました。
背景と課題感
なぜこのタイミングで「テストケースの考え方・テスト駆動開発（TDD）勉強会」を企画したのかというと、AI駆動開発により開発スピードが非常に高速化する中で、「人間の認知を超えて氾濫するコードに対して如何に品質を保証するのか？」という問いが自分の中にあり、一つの鍵としてTDDがあると考えているためです。
テストは仕様とコンテキストを同時に表現してくれるガードレールです。「少なくともテストをPASSしたコードである」という安心を得られるだけでなく、AIに対してもテストを入力として渡すことで期待する振る舞いを明示できます。実装を二人三脚で進める際の共通言語として、テストの重要性はむしろ増していると感じています。
また、最近はテストリストそのものをAIに生成させる場面も増えています。生成されたテストが要件を十分に網羅しているか、境界値や異常系が抜け落ちていないかを最終的に判断するのは人間です。ザルなテストコードを粗製乱造しても品質は高まりません。だからこそ、TDDのワークフローだけでなくテスト設計の勘所を自分たちの言葉で整理し直しておきたいと考えました。
勉強会の準備
スライド作成には、Slidevを使いました。最近、自社ロゴ入りのカスタムテンプレート作りを始めています。この辺りもいずれ取り上げたいと思います。スライド作成方法についてはこちらに書いたので興味のある方は読んでいただけると嬉しいです。
参考資料
今回の勉強会では次の2冊をベースに進めました。詳細はこちらを参照してください。
テストケース設計のポイント
まずはテストケース設計の基本を押さえるために、ソフトウェアテスト技法ドリルの第3章までをぎゅっとサマリーにして共有しました。
紹介したテスト技法
具体的には、以下の技法を題材にしています。
- ピンポイントテストで臭う箇所をテストする
- 境界値分析でドメインに寄り添ったテストケースを作成する、エッジケースを漏れなく拾う
- ディシジョンテーブルで条件と結果の組み合わせを整理する
ディシジョンテーブル演習
ここでいうディシジョンテーブルは、行・列で条件と結果を一覧化し、どの条件が成り立ったときにどの結果になるのかを網羅的に確認する表形式の手法です。表の空欄を埋めていくことで、条件漏れや矛盾が一目で分かるようになります。
そのうえで、実際のプロダクト仕様を題材にしながら、ディシジョンテーブルを組み立てる演習を行いました。その後各自の作成したディシジョンテーブルを見つつ、いくつかの論点について議論しました。演習を勉強会に含めた理由は、抽象的な説明だけで終わらせず、現場の仕様をベースに具体的なテストケースを洗い出すプロセスを体験してもらうためです。議論する場を整えることで、メンバー間の認識合わせが進むと感じました。
盛り上がったポイント
ディシジョンテーブルを作る過程では、人によって条件の捉え方が微妙に異なることも分かり、仕様認識の差分が浮き彫りになりました。また、要件定義からは漏れる「未入力の場合はどうなるか」「APIからNullが返ってきたときの扱い」といった暗黙の前提こそ、AIにコンテキストを与える際には明示的に伝える必要があるポイントだと再確認しました。
さらに、境界値の扱いでは「500未満」といった表現よりも「499まで」「500を含む」といった具体的な値で条件を記述する重要性を共有しました。こうした粒度でディシジョンテーブルやテストリストを整理することで、仕様の抜け漏れを減らし、AI生成コードのレビュー時にもガードレールとして機能するのではないかと考えています。
テスト駆動開発のワークフロー
後半ではTDDの基本的なワークフローをおさらいし、明確な実装・仮実装・三角測量などTDDのキーフレーズを紹介しました。TDDでは、まず失敗するテスト（Red）を書き、最小限の実装でテストを通し（Green）、最後にリファクタリングでコードを整える（Refactor）というサイクルが基本になります。各キーフレーズはそのRed→Green→Refactorをスムーズに回すための考え方です。
紹介したキーフレーズ
- 明確な実装：頭の中に浮かんだ実装をコードに落とす。書くべきコードが明確な場合は明確な実装を続ける
- 仮実装：ベタ書きなどを駆使してテストをPASSさせる。明確な実装を続ける中で予期しないレッドバーに直面した場合など
- 三角測量：複数のテストケースを書いて一般化を導き、実装を洗練する
演習の進め方
また、Claude Codeのカスタムコマンドを用意し、Coding DojoのPotterカタを題材に実装演習を行いました。レッドバーからの切り返しや仮実装→明確な実装への移行を、参加者に実際に体験してもらう構成です。
演習からの気づき
演習では、AIとの協業をどう設計するかという観点が盛り上がりました。たとえば「AIはかなり明確に実装まで見えているはずで、厳密なTDDをそのまま当てはめるのはやや茶番に見える」といったコメントが出たり、「TDDサイクルを徹底することでコンテキストを徐々に蓄積し、アウトプットの品質を高めることに繋がるのではないか」という話題が上がったりしました。
TDDの型をなぞるだけでなく、AIアシスタントの特性をどう取り込むかを議論できたのが印象的でした。
教材としてリポジトリを公開していますので、興味があればこちらも参照いただければと思います。
今後の展望
今後は次のようなトピックを取り入れて、継続的に勉強会をアップデートしていく予定です。
- テスト技法ドリル第3章以降の要素の取り込み
- AIアシスタントを活用したテスト駆動ワークフローの最適化（プロンプト設計やレビュー体制の工夫）
- 現場で実際に遭遇した仕様変更・バグ修正ケースを題材にした教材のアップデート
おわりに
テスト設計とTDDの基礎に立ち返り、AI時代にもより高い品質のプロダクト作りを目指していきたいと考えています。今回の取り組みが、同じような課題を持つ方の参考になれば幸いです。
Discussion