こんにちは！
この記事はソフトウェアテストの小ネタ Advent Calendar 2023 14日目の記事です。
ISTQBの用語集の「テスト条件」と「カバレッジアイテム」ってなんなんでしょう？
これまで雰囲気でこれらの用語を理解していた気がするので、整理してみました。
用語の定義
テスト条件（test condition） Version3
テストのための根拠となる、コンポーネントやシステムのテストが可能な一部分。
カバレッジアイテム（coverage item） Version2
テスト技法を使用して、一つ以上のテスト条件から導出される属性または属性の組み合わせ。テスト実行の完全性を測定するために使用する。
調べていたところ秋山さんのブログに辿り着きました。
第192回： 「ソフトウェアテストしようぜ」9 CDプレイヤー（2. テスト分析の中編）
第195回： 「ソフトウェアテストしようぜ」12 CDプレイヤー（テストケース 中編）
その中で、秋山さんは
- テスト条件とは『テストによって確認できるもの/こと』
- カバレッジアイテムとは『テスト条件で確定していないことをみつけて、そのバリエーションを「どこまで」やるかを決めたもの』
と平易な言葉で説明されています。
テスト条件とは
ご紹介したブログの中でも引用されていますが、改めてテスト条件について記述されているISTQB Advanced Level シラバス テストアナリストを読んでみます。
一般的には、テスト条件を様々な詳細度合いで定義することが望ましい。まず、テスト
をするための大まかな対象を定義するために、「画面 x の機能性」といったハイレベ
ルの条件を識別する、次に、具体的なテストケースのベースとして、「画面 x では、正
しい長さよりも１桁足りないアカウント番号を拒否する」といった、より詳細な条件を識
別する。このような階層アプローチを使用してテスト条件を定義することにより、ハイレ
ベルのアイテムに対するカバレッジを十分なものにすることができる。このアプローチ
を使うことで、テストアナリストは、まだ洗練されていないユーザーストーリーに対する
ハイレベルなテスト条件を定義する作業を開始できる。
"テスト条件"として抽出できるものには、さまざまな抽象度があって良いようです。
「画面 x の機能性」という抽象的なものもテスト条件になるんですね。
カバレッジアイテムとは
次にカバレッジアイテムについて。
カバレッジとは、対象をどれくらい網羅しているかという指標なので、
どれくらい網羅しているかを示すためのアイテムと考えると、わかりやすいですね。
「テスト条件」や「カバレッジアイテム」の具体例
具体例を考えてみます。
スマートフォンのプッシュ通知を考えてみましょう。
例えば、「OS」。これはテスト条件ですよね。「文字列」もテスト条件。「文字数」もテスト条件。
では「Android」や「iOS」はカバレッジアイテムになるのでしょうか。
これはテスト条件でどのようなふるまいを確認したいのか、どのようなバグを出したいのかによっても変わってきそうです。
OSバージョンによる違いがないと断言できるなら、「Android」と「iOS」だけでカバレッジが示そうです。
一方で、OSバージョンによるふるまいの差異を見つけたいのならば、「iOS17」や「iOS16」などメジャーバージョンまで示さないと、カバレッジを示せないかもしれません。
同様に考えると、「iOS16.x」などマイナーバージョンまで示さないと、カバレッジを示せないかもしれません。
重要なのは、そのテスト条件で何をどこまで確認したいのかを明確にし、説明できることなのかもしれません。
ところで、プッシュ通知を題材にする必要なかったのでは。。
さいごに
小ネタということで、取り留めもない記事になってしまいましたが、
今の自分が解釈している「テスト条件」「カバレッジアイテム」について書いてみました。
テスト用語って、人によっても違うし、現場によっても違うし、何ならその道xx年の方でも異なる解釈をしていたりするので、
具体例を交えて、自分なりの解釈を発信していくことが重要なのかなと感じました。