こんにちは、QAエンジニアのヨシナです。
毎週金曜日、QAチームでテストプロセスを振り返る会議を行っています。使用するテスト手法、テスト仕様書のレビューフロー、工数の見積もり方法などについて議論しています。最近の会議では、テスト中に「テストケースに必要な項目が不足している」と感じたことを議題として取り上げました。
本記事では、テストケースに必要な項目について話し合った結果を書きます。
QAチームでは以下の項目をテストケースに使用しています。
| 項目名 | 説明 |
|---|---|
| 番号 | テストケースのID |
| 機能 | テスト対象の機能 |
| 画面種別 | テストを実施する画面の分類 |
| 対象画面名 | テスト対象の画面名。（画面がない場合は機能名を記載） |
| 要素（大、中、小） | テスト対象の要素名やシナリオ |
| 前提条件・テストデータ | テストで使用する前提条件やテストデータ |
| 手順 | テストの実施方法 |
| 期待結果 | 手順を実施した際に得られるべき結果 |
| 確認担当者 | テスト担当者 |
| 確認結果 | テストの結果が期待結果と一致するかを示すステータス |
| 備考 | テストケースに関する補足情報 |
以下の項目の追加を提案しました。
これらの項目はトレーサビリティを向上させる効果があります。たとえば、テストした機能でバグが発見された場合、実行日付やビルドバージョンが記録されていれば、以下のようなメリットがあります：
結論として、実行日付とビルドバージョンの項目は採用されませんでした。
現状ではQAチームがバグの混入タイミングを把握する必要がなく、バグの影響範囲の調査は主に開発チームが担当しているためです。また、テストケースをExcelで管理しています。手動で実行日付を入力する必要があるため、テスターへの負担が増えることが懸念されました。
テストケース管理ツールを導入すれば実行日付を自動登録する機能が利用できるため、将来的にツールを導入した際には再度検討する予定です。また、QAチームがバグ調査を行う必要が生じた場合にも、改めて項目追加を議論することになりました。
テスト関連ツールを提供しているBrowserStackによると、以下の項目がテストケースにおける標準項目とされています。
「テスト結果」を独立した項目としては設けていませんが、代わりに「備考欄」がその役割を果たしています。
テストケースに含めるべき項目は企業ごとに異なりますが、重要なのはチームの業務やプロセスに合った項目を採用することです。今後も、テストケースで情報が不足していると感じた際には、必要な項目についてチームで改めて議論していきたいと思います。
当社のビジョンは『世界一「学びやすく、分かりやすく、続けやすい」学習手段を提供する』ことです。革新的な教育サービスを作り成長させていく事で、オンライン教育分野でナンバーワンの存在となり、世界に展開していくことを目指しています。
Be the first to comment
