ソフトウェア開発におけるテスト設計手法は多くありますが、ユーザー視点を重視する開発ではユースケース駆動開発をベースにしたテスト設計が有効となります。 今回、ユースケース駆動開発ベースのテスト設計手法についてご紹介いたします。
ユースケース駆動開発とは何か？
ユースケース駆動開発とは、Use Case Driven Developmentと呼ばれ、システムの利用者であるユーザーの視点から「ユースケース(利用シナリオ)」を作成し、それをベースに設計、実装、テストを進めていく手法です。
※ここでいうユースケースは、ユーザー(アクター)とシステムがどのようにかかわるかを記載したもので、以下のような構成要素を持ちます。
| 構成要素 | 説明 |
|---|---|
| アクター | システムを利用する主体(主にユーザー) |
| ベーシックフロー | 正常な操作の流れ |
| 代替フロー | 分岐や例外的な操作の流れ |
| 前提条件 | ユースケースの開始条件 |
| 終了条件 | ユースケースの終了条件 |
テスト設計への展開方法
ユースケースの構成要素はテスト設計において以下のように分類できます。
| 構成要素 | テスト観点 |
|---|---|
| ベーシックフロー | 正常系確認 |
| 代替フロー | 異常系や例外系確認 |
| 前提条件 | 初期状態の確認 |
| 終了条件 | 結果の妥当性確認 |
| アクター | 権限や操作の違いによる分岐確認 |
このようにユースケースを元にテストケースを作成することで、ユーザー操作に即した網羅的なテスト設計が可能になります。
使用例
以下に「携帯電話から電話をかける」というユースケースを手法に従って作成してみます。
ユースケース名
携帯電話から電話をかける
前提条件
- 携帯電話の電源が入っている。
- SIMカードが有効である。
- 電波が利用可能な状態である。
ベーシックフロー
- ユーザーが電話アプリを起動する。
- ユーザーが電話番号を入力する、または連絡先を選択する。
- ユーザーが「発信」ボタンを押下する。
- 携帯電話が指定された番号に発信する。
- 相手が応答する。
- 通話が開始される。
代替フロー
A1.無効な電話番号
- 3a.ユーザーが無効な番号を入力する。
- 3b.システムが「無効な番号です」と表示し発信を中止する。
A2.圏外
- 4a.発信操作後、システムが「圏外のため発信できません」と表示する。
- 4b.ユーザーに再試行またはキャンセルの選択肢を提示する。
A3.相手が応答しない
- 5a.一定時間応答がない場合、通話が自動的に終了し「応答なし」を表示する。
A4.通話中に切断
- 6a.通話中に電波障害で切断する。
- 6b.システムが「通話が切断されました」と通知する。
終了条件
- 通話が開始される、または適切なエラーメッセージが表示される。
以上の情報を整理すると以下のようなテストIDに分けられます。
より詳細な振る舞いをこちらをベースに作成していく形となります。
| テストID | 条件 | 操作 | 期待結果 |
|---|---|---|---|
| TC01 | 電波あり、番号有効 | 発信 | 通話開始 |
| TC02 | 無効な番号 | 発信 | エラーメッセージ表示 |
| TC03 | 圏外 | 発信 | 発信不可通知 |
| TC04 | 相手応答なし | 発信 | 自動切断 |
| TC05 | 通話中に電波切断 | 通話継続 | 切断通知 |
メリット
- ユーザー視点による網羅的なテスト設計が可能になる。
- ユースケースは実際の利用シナリオに直結している。
- ユーザー操作に影響する不具合を早期に検出できる。
- 作成したテストケースを回しながら開発を進めることでユーザー操作の優先度に応じた実装が可能となる。
- 仕様書の記載が不十分であってもユーザー視点によるユースケースの作成は可能なため、テスト設計を早期に開始できる。
注意点
- ユースケースの記載粒度が曖昧であったり不適切だとテスト設計も不十分になるので、記述内容の標準化とレビューが重要になります。
- 記載の仕方には慣れが必要です。慣れるまでは作成に時間を要するケースが多いです。
- 最初から細かいユースケースの作成をするのではなく、ベーシックフローの作成を行った後、開発が進む中で詳細化していく進め方が良いです。
