はじめに
HULFT開発部はQuality Trackerというテスト管理ツールを導入することになり、所属のAPI Gatewayチームも利用を開始いたしました。
既存テストケースとQualityTrackerのフォーマットが違っているため、移行する際に工夫が必要です。また、既存テストケースには改善箇所があり、今後のテスト効率と品質向上を図るため、移行を機にテストケースの見直しを行っています。この記事では、テストケースの移行内容と改善点を記載します。
テストケース移行の実施内容
移行時の実施内容を説明します。
移行元の既存テストケース（Excel形式）に以下の項目があります。
- 階層１ （カテゴリ名）
- 階層２ （大項目）
- 階層３ （中項目）
- 階層４ （条件１）
- 階層５ （条件２）
- 階層６ （条件３）
- 優先度
- 検証内容
- 備考
移行先のQualityTrackerの項目は以下になります。
※インポートファイルはCSV形式
- 機能(大)
- 機能(中)
- 機能(小)
- タイトル
- 手順
- 期待値
- ノート
- テスト観点
- テストスイート
- タグ
- 見積もり(分)
- スペック
- 優先度
既存テストケースの項目をQualityTrackerのどの項目に移行するかについて、以下のように実施しました。
| 移行元（既存テストケース） | 移行先（QualityTracker） |
|---|---|
| 階層１ （カテゴリ名） | 機能(大) |
| 階層２ （大項目） | 機能(中) |
| 階層３ （中項目） | 機能(小) |
| ※1 | タイトル |
| 階層５ （条件１） | 手順 |
| 階層５ （条件２） | 手順 |
| 階層６ （条件３） | 手順 |
| 検証内容 | 期待値 |
| 備考 | ノート |
| ※2 | テスト観点 |
| ※3 | テストスイート |
| ※4 | 見積もり(分) |
| ※5 | スペック |
| 優先度 | 優先度 |
※1～※5は、既存テストケースにない項目のため、移行先のインポートファイルに記載する必要があります。
- タイトル：テストケースの目的や要約（記載例：○○詳細画面の表示確認）
- テスト観点：テストの観点（記載例：基本品質）
- テストスイート：テストケースのグループ名（記載例：画面テスト）
- 見積もり(分)：テスト実行の見積もり時間
- スペック：テストを行う際に必要な詳細情報
テストケースの改善ポイント
既存のテストケースは、前提条件の記載がない、期待結果の記述が曖昧などの問題があります。
テストケースを明確化するためには、誰が実施しても同じ結果が得られるように、具体的な手順、条件、期待結果を記述することが重要です。そのため、以下のポイントを意識して改善を行っています。
- 手順実施前の前提条件の追記
※前準備が必要な場合は提示しておく
（例）
| 改善前 | 改善後 |
|---|---|
| 手順：●●アカウントで管理画面にログインする |
前提条件：●●アカウントが作成されていること 手順：●●アカウントで管理画面にログインする |
- 表示内容の詳細化
表示内容が「エラーメッセージが表示される」場合は、正確なメッセージ内容や表示場所を記述します。
（例）
| 改善前 | 改善後 |
|---|---|
| 期待値：エラーメッセージが表示されること | 期待値：画面の上部に赤文字で「必須項目が入力されていません」が表示されること |
- 期待結果の明確化
（例）
| 改善前 | 改善後 |
|---|---|
| 期待値：ログイン情報が正しく更新されること | 期待値：ログイン日時が最新になり、表示形式が仕様書通りであること |
上記の例以外、時間・数値の確認がある場合は、具体的な数値を指定するようにします。曖昧な表現を避け、客観的な基準でテストの合否が判断できるように改善しました。
最後に
テストケースをツールに移行する機会に、改めてテストケースの記載内容を整理できると感じでいます。
テストケースを作成するとき、条件や手順をどこまで記載すればよいか、いつも悩むところですが、「明確性」と「簡潔性」を意識して作成できれば、テスト効率の向上につながると思います。
今回はテストケースの改善について話してみました。すこしでも共感してもらえるとうれしいです。
お読みいただき、ありがとうございました。