見出し画像

第288回: 「ALTAのテキストをつくろう」43 (ユースケーステスト/後編)

◀前の記事へ 次の記事へ▶︎


≡ はじめに

前回は、「3. テスト技法」の「3.2 ブラックボックステスト技法」の「3.2.7 ユースケーステスト」の中編として、「ユースケーステストの適用、制限/注意事項」について書きました。

前回の一番大切な箇所を引用します。

ユースケースがあっても、全面的に信用しないようにと書いてあります。
そもそも要求は曖昧なものですから、それをテストベースにするユースケーステストはそのこと(ユースケースが、曖昧で抜け漏れの可能性が高いこと)を十分に承知して必要に応じて他のテスト技法と併用してくださいということです。

前回より

この「テストベース(テストをつくるときに参考にした仕様書など)を信用しすぎないことや、テストベースに書かれていないことをどうやって補ってテストをつくるか?」については、昨年のSQiP研究会のテスト分科会のテーマでした。
今年のSQiPシンポジウムでグレードアップしたものが発表されると思いますので、ぜひお楽しみに。

前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「3.2.7 ユースケーステスト」の後編として、「ユースケーステストのカバレッジ、検出できる欠陥の種類」について書きます。



≡ 前回の復習

以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。


𝕏によるアンケート結果

投票の結果、選択肢1の「コンポーネントテストにも使用することがある」が48.6%と最も多く、正解も1です。

複数のコンポーネントがまとまったコンポーネンツに対して統合テストのときにユースケーステストをすることはありますが(選択肢2)、コンポーネントテストは一つひとつの小さい汎用部品に対するテストですので、ユースケーステストをすることはありません。

⚠️ ISTQBがそう言っているだけの話であることに注意が必要です。

個人的にはテスト技法とテストレベルは完全に切り離して理解したほうが良いと考えています。
それはそれとして、試験に対しての基本的なコンセンサスは抑えましょう。

今回のnoteのテーマに移ります。



≡ ユースケーステストのカバレッジ、検出できる欠陥の種類


■ ユースケーステストのカバレッジ

JSTQBのALTAシラバスより該当箇所の全文を引用(太字筆者)します。ちょっと長いですが、ここは、ISTQBがそう考えているという部分なので、試験に合格するためには、そのまま受け入れるしかない箇所です。

ユースケースの受け入れ可能な最小カバレッジレベルは、基本的な振る舞い用の1つのテストケースと、代替およびエラー処理の振る舞いのそれぞれをカバーするのに十分な追加テストケースを用意することである。最小テストスイートが必要な場合、複数の代替の振る舞いが相互に互換性があればそれらを1つのテストケースに組み込むことができる。診断能力を高める必要がある場合(例えば、欠陥を特定しやすくするため)、代替の振る舞いごとに1つのテストケースを追加で設計することがある。ただし、入れ子になる代替の振る舞いでは、いくつかを単一のテストケースに融合する必要がでてくる(例えば、「リトライ」をする例外の振る舞い内での「終了」と「非終了」の代替の振る舞いなど)。

ユースケーステストは「K4」ですので、上記の通り覚えて、ユースケーステストのテストケースをつくれるようになるしかないのですが、太字の所(基本的な振る舞い用の1つのテストケースと、代替およびエラー処理の振る舞いのそれぞれをカバーする)以外が問われたら「自分ならこう作る」でと考えて選択すればいいと思います。

というのは、テスト対象によって公式通りにいかないので、この通りにつくることが常に正解とは限らないからです。


■ ユースケーステストの検出できる欠陥の種類

JSTQBのALTAシラバスより該当箇所の全文を引用します。

欠陥には、定義済みの振る舞いの誤った処理、代替の振る舞い欠落、提示された条件の誤った処理、十分に実装されていない、または不適切なエラーメッセージがある。

ユースケーステストが「振る舞い」を確認するテストであることを抑えていれば十分です。



≡ JSTQB ALTA試験対策

いつものことですが、まずは、「学習の目的」を確認します。

TA-3.2.7 (K4)ユースケーステストを適用して、特定の仕様アイテムを分析しテストケースを設計する 。

ALTAシラバス29ページ

「K4」なので「理解」して「適用」できるだけではなく「分析」まで求められる重要な項目ということです。試験問題には、ユースケーステストをつくることができるかどうか、あるいは、(定義が広いので)ユースケーステストではないものを選ばせる問題が出ると思います。

《問題》
 ユースケーステストで検出できると期待する欠陥の種類【ではないもの】はどれですか。

1. 定義済みの振る舞いの誤った処理
2. ある状況下で実際に起こるべきことに関する情報がないことや矛盾
3. 代替の振る舞い欠落
4. 十分に実装されていない、または不適切なエラーメッセージ

答えは次回に書きます。



≡  おわりに

今回は、「ユースケーステストのカバレッジ、検出できる欠陥の種類」がテーマでした。

ユースケーステストは技法と言えるほど整理されていないと思います。ですから、今後、もっと良い方法が生まれたり、別のテスト技法が拡張されて、それに代替されたりすると思います。
言い換えれば、「ユースケーステスト」について独自のテスト手法を作って発表するチャンスです!

次回は、「3.2.8 技法の組み合わせ」について書きます。こちら、シラバスには10行しかないのですが、実務においてもとても大切な箇所です。


いいなと思ったら応援しよう!