第287回： 「ALTAのテキストをつくろう」42 （ユースケーステスト／中編）
◀前の記事へ 次の記事へ▶︎
≡ はじめに
前回は、「3. テスト技法」の「3.2 ブラックボックステスト技法」の「3.2.7 ユースケーステスト」の前編として、「ユースケーステストの定義」について書きました。
コーバーンという人の「雲・凧・波・船・海・魚・泥・貝」の絵を紹介できて満足です。興味を持たれた方は、『ユースケース実践ガイド』をお読みください。絶版なので図書館で借りて読むといいと思います。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「3.2.7 ユースケーステスト」の中編として、「ユースケーステストの適用、制限／注意事項」について書きます。
≡ 前回の復習
以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、選択肢4の「システムの導入で残業時間が削減されることのテスト」が86.2%と最も多く、正解も4です。
他の選択肢についてですが、1の「カーナビで道を外れたときの動作のテスト」は、カーナビの最終試験で、実車にテスト対象のカーナビを積んで市街地を走るシナリオテスト（ユースケーステストの王道）を思い浮かべられると思います。
そうされた方が多かったのか、誰も投票しませんでした。
「2. 期限切れのクレジットカードが使えないことのテスト」「3. 150円入力して150円の缶コーヒーを購入できることのテスト」となると徐々にシナリオ色が減り、3は単なる機能テストだよなあ……と選びにくくなっていきます。機能についてもその振る舞い記述があればユースケーステストを作ることができます。
そして正解の「4. システムの導入で残業時間が削減されることのテスト」。
なんとなく、コレはユースケーステストジャナイゾ感はあるものの、【ユースケーステストではないこと】を後輩に説明するのはやっかいだなと思われたんじゃないかと思います。前回で言えば、「雲・凧」といったビジネスレイヤーのユースケーステストに見えなくもないからです。
というふうにモヤっとしてもらうための問題なので、復習もモヤっとしたままとし、今回のnoteのテーマに移ります。
≡ ユースケーステストの適用、制限／注意事項
■ ユースケーステストの適用
JSTQBのALTAシラバスより該当箇所の全文を引用（太字筆者）します。
ユースケーステストは、通常、システムテストレベルおよび受け入れテストレベルで適用する。また、コンポーネントまたはシステムの振る舞いがユースケースで指定されている場合には、統合テストにも使用することがある。ユースケースはシステムの実際の使い方を表すので、性能テストのベースとなることが多くある。ユースケースが示すシナリオを仮想ユーザーに割り当てることで、システムに現実的な負荷をかけることがある（負荷および性能要件がユースケース内、またはユースケースのために仕様化されている場合）。
太字のところで、ちょっと気を付けてほしいことは、「コンポーネントテストにおけるユースケーステストの話はしていない」という点です。原文は、
It may also be used in integration testing if the behavior of the components or systems is specified by use cases.
そして、JSTQBの翻訳は以下です。
また、コンポーネントまたはシステムの振る舞いがユースケースで指定されている場合には、統合テストにも使用することがある。
細かいですが、「コンポーネントまたはシステムの振る舞いが」は、「コンポーネントやシステムの振る舞いが」の方が良いと思います。
ここでいっているcomponentsは、複数形であることから分かるとおり、componentが複数ある大きなコンポーネントを表しているからです。
意訳をすれば、「あなたの組織ではコンポーネントと呼んだりシステムと呼んでいるものの振る舞いをテストするなら、統合テストでもユースケーステストをすることがあるよ」ということだと思いますので、「または」で対照させずに「や」とするほうが良いと思うからです。
部品は、英語でpartといいます。日本語でもパーツというからおなじみです。
（日本語のようにパーツと発音すると複数形のpartsと思われるので注意が必要ですが、まあ同じ意味です）
componentも部品ですが、ステレオコンポ（例が古くてすみません。アンプとかスピーカーとかレコードプレーヤーがコンポーネントです）のように「機能を持った（全体システムから見たら）部品」の意味です。
このように、componentは、partより大きいのにさらにシラバスでは、複数形のsが付いているので大きなまとまりであると感じます。
※ 部品と訳される英単語には他にもmoduleがありますが、こちらは技術者が使う言葉で、ほぼコンポーネントと同じものです。
moduleは、他との技術的な独立性がより高く、取り換えや、作るときの分担をするまとまりをイメージさせます。
■ ユースケーステストの制限／注意事項
ユースケースがあっても、全面的に信用しないようにと書いてあります。
そもそも要求は曖昧なものですから、それをテストベースにするユースケーステストはそのこと（ユースケースが、曖昧で抜け漏れの可能性が高いこと）を十分に承知して必要に応じて他のテスト技法と併用してくださいということです。
≡ JSTQB ALTA試験対策
いつものことですが、まずは、「学習の目的」を確認します。
TA-3.2.7 （K4）ユースケーステストを適用して、特定の仕様アイテムを分析しテストケースを設計する 。
「K4」なので「理解」して「適用」できるだけではなく「分析」まで求められる重要な項目ということです。試験問題には、ユースケーステストをつくることができるかどうか、あるいは、（定義が広いので）ユースケーステストではないものを選ばせる問題が出ると思います。
《問題》
ユースケーステストに対して【誤っているもの】どれですか。
1. コンポーネントテストにも使用することがある
2. 統合テストにユースケース記述がある箇所に対して使用する
3. 通常、システムテストで適用する
4. 通常、受け入れテストで適用する
答えは次回に書きます。
≡ おわりに
今回は、「ユースケーステストの適用、制限／注意事項」がテーマでした。
曖昧なユースケースを対象とするテスト技法です。ユースケースに書かれていることだけをテストしても良いユースケーステストにならないことは肝に銘じておく必要があります。
ユースケース図からテストをつくるのではなく、ユースケース記述の記述からテストを作ります。そしてほとんどの場合、デシジョンテーブルを作成します。また、以前のnoteに書いたシナリオを補足する方法も有効です。
ところで、今回のキャッチイメージですが、本文とは関係ありません。
いろいろなユースケースがあることのイラストをnoteで探してみたのですが、見つからなくて、かわいいのをみつけたのでこれにしました。
次回は、「3.2.7 ユースケーステスト」の後編として、「ユースケーステストのカバレッジ、検出できる欠陥の種類」について書きます。
この記事が気に入ったらサポートをしてみませんか？