テスト設計チュートリアル ちびこん編概要

テスト観点（テストすべきこと）を整理して、網羅的に挙げよう
テストすべきことを挙げきることは、バグを防ぐために大切な考え方です。ここではテストすべきことを網羅的に挙げるとはどのようなことか、どのように行ったらよいかについて、Myersの三角形問題を題材にして具体例を挙げながら説明します。また、テストは網羅的に行うことも必要ですが、効率的にバグを見つけるためにピンポイントでバグを狙って検出する、というテスト設計も必要です。ピンポイントでバグを狙うためのテスト観点やその導き方についても合わせて紹介します。
テストフレーム（テストケースの構造）を考えよう
テストすべきことをテスト観点として列挙したら、それらをまとめてテストケースにしていきます。その時にテストケースの構造を考えると、網羅しやすいテスト設計になります。ここではテストケースの構造とはどのようなことか、どのようにまとめていったらよいかについて説明します。
テストコンテナ（テスト観点やテストフレームをまとめたもの）とその間の順序関係を考えよう
テストケースの構造をテストフレームとしてまとめたら、テストの全体像を考えてみましょう。皆さんは単体テストや結合テスト、システムテストといったテストレベル、負荷テストや動作環境変更テスト、性能テスト、セキュリティテストといったテストタイプ、1回目の機能テストや2回目の回帰テストといったテストサイクルなどで、テストの全体像を捉えていると思います。こうしたテストコンテナとしてうまくテスト観点やテストフレームをまとめると、見通しの良いテスト設計になり、後工程や後プロジェクトでテストしやすくなります。ここではテストの全体像とはどんなものなのか、どのようにまとめていったらよいかについて説明します。
テスト観点からテスト値を網羅しよう
3.までは徐々にテストの全体像を捉えていく話でしたが、4.では逆に詳細なテストデータなどを決めていきます。ここではテストデータを網羅するパターンとして、範囲タイプ、一覧表タイプ、マトリクスタイプ、グラフタイプの4つのテストモデルを紹介し、それぞれの網羅基準とテストデータの導き方を説明します。
「テスト開発」を意識して進めてみよう
このように体系的にテストケースを設計していく行為全体をテスト開発プロセスと呼びます。ここまで説明してきたことをプロセスの側面から総括します。
前回から見えてきたU-30での課題
前回のU-30の審査から見えてきた、テスト設計を行う上で見えてきた課題について示します。