第248回： 「ALTAのテキストをつくろう」11 （テスト設計 テストケースの設計 前編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は「テスト設計のプロセス」の「ローレベルテストケースとハイレベルテストケースの長所と短所」について書きました。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「1.4 テスト設計」のうちの「1.4.2 テストケースの設計」の前半（テストケースとは何か？）について書きます。
≡ 前回の復習
以下は前回出したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、4が64.5%と最も多く、正解も4です。
ところで、正解者が多いといっても64.5%は微妙な値です。3分の2が66.7%であることを考えると、約1/3は不正解を選択しているからです。ということで、今回は解説をします。
まず、今回の問題は、「以下の選択肢で誤っているものを選びなさい」ですから、注意が必要です。ローレベルテストケースの特徴ではないものを選ばないといけないからです。
問題文の読み損ねによる失点はもったいないです。
選択肢1の「経験が浅いテスト担当者に向いている」が不正解ということは「ローレベルテストケースは経験が浅いテスト担当者に向いている」という命題が正しいということになります。
ローレベルテストケースは、ハイレベルテストケースよりも詳細で具体的に書きますから、経験が浅いテスト担当者でも間違えずに、テスト設計者が期待した通りのテストを実行することができます。
以下は、私の失敗談です。
「半角英数字で16文字までの文字列をパスワードとして使うことができる」というパスワード登録機能の仕様があったので、「1文字から16文字までのパスワードが登録できることを確認する」というテストケースを書いてテスト担当者に渡しました。テストは無事に終わり、パスワード登録機能に欠陥は見つかりませんでした。
しばらくはユーザークレームがなったのですが、リリースの半年後くらいに「長いパスワードを受け付けない」という不具合が発生してしまいました。
不具合の原因は、「他の製品からパスワード登録機能のモジュールを流用したときに、パスワードの最大文字数を12文字から16文字に直すのを忘れたので、13文字から16文字のパスワードが登録できなかった」でした。
ところで、「1文字から16文字までのパスワードが登録できることを確認する」テストは合格しています。どうしてテストは合格しているのだろう？と不思議に思いました。
テストを実行した人に「このテストはどうだった？」と訊くと「普通にパスワードは登録されました。」と言います。
これはもう、実際にやってもらうしかないと思って、目の前でテストをしてもらったろころ、【パスワードに「abced」を登録していた】ことがわかりました。確かに、このテストでは、「文字数13文字～16文字のパスワードは登録できない」という不具合はみつかりません。
これは、テスト担当者の問題というよりも、「1文字から16文字までのパスワードが登録できることを確認する」というテストケースの抽象度がテスト担当者と合わなかったことが原因です。
私が、「1文字のパスワードが登録できることを確認する」と「16文字のパスワードが登録できることを確認する」もしくは、もっとローレベルに「”a”という1文字のパスワードが登録できることを確認する」と「”abcdefghijklmnop”という16文字のパスワードが登録できることを確認する」というローレベルテストケースを書けばよかったのです。（0文字と17文字のテストもした方がベターですね）
※ もしくは、テスタ担当者に事前にテスト教育を行って、テストケースに「AからBまでの数値」と書いてあったら、境界値分析を行って、実際のテストでは下限Aと上限Bのテストを実行すると伝えておけばよかったのです。
選択肢2の「テスト自動化の実装に費やす時間を削減する」は、【実装】という個所がポイントです。
これが、「テスト自動化の全体に費やす時間を削減する」でしたら、変わらないか、かえってハイレベルテストケースで書いたテストケースの方が自動スクリプトをつくりやすいから、ローレベルテストケースをもとにして自動テストスクリプトをつくることは時間がかかると思います。
試験では「設問の意図を読み取ること」と「一番あてはまるものを選択する」ことが大切です。
したがって、実際のALTAの試験のときには選択肢2はいったん保留にしておいて、ほかに候補が現れてこなければ選ぶのが良いでしょう。
選択肢3の「（ローレベルテストケースは、）実行時にテスト担当者の創造力を制限する傾向にある」はローレベルになればなるほど、具体的なテストケースになるわけですから、テスト担当者が自由に決めることができる部分は減ります。
これを言い換えれば、「テスト担当者の創造力を制限する傾向にある」となりますから、この選択肢の主張は正しいので、問題の解答としては誤りということになります。
ISTQBの用語集に、「ローレベルテストケース」の同義語として「具体的テストケース(concrete test case)」があります。
「コンクリート」は、「鉄筋コンクリート」でおなじみのコンクリートです。「ハイレベルテストケース」を「ざっくりとしたテストケース」、「ローレベルテストケース」を「コンクリートのようにガッチガチのテストケース」とイメージしておくと良いと思います。
でも、あらためて、「セメント」や「生コン」とコンクリートの違いを聞かれたら「？？？」かもしれません。
コンクリートとセメントの違いは原料にあります。 セメントはコンクリートの原料で、石灰石などを焼成し、細かく粉砕して粉状にしたものをセメントと言います。 そしてコンクリートは、セメントに砂・砂利・水を加えて混ぜてドロドロにして、それを固めたものになります。 ちなみにドロドロの状態のコンクリートが生コンです。
ソフトウェアテストの講師をしていると、たまに「先生！ コンクリートとセメントの違いは何ですか？」といった斜め上の質問を受けることがあります。
「あとで、調べて回答します」とやり過ごして、休憩時間にググります。（笑）
最後の選択肢4の「（ローレベルテストケースは、）テストの再現能力が低く検証を困難にする」は、全逆のことを言っていますので、こちらの選択肢が正解となります。
再現能力ついでに思い出したのですが、テストを実行してバグを見つけたときの「バグ票」に記載する再現手順は、できるだけ具体的に「ローテストケース」のように書きましょう。
初心者のテスト担当者にありがちな話なのですが、バグ票の再現手順を（その方が良かれと思って）ハイレベルで書く人がいます。
たとえば、上に書いたパスワード文字数を例にしたら、再現手順に「長いパスワードを入力したら受け付けられなかった」と書く人がいます。
そうではなく、
「長い文字列のパスワードが登録できることを確認する目的で、“12345678901234”というパスワードをxxxという画面で手入力したらyyyというエラーがでて登録できなかった。その後、“abcde”では登録できた。」
というように、ローレベルを心がけてくださるほうがデバッグのための調査が楽になります。
以上で復習は終わりです。長かったー。
≡ テストケースとは何か？
ALTAシラバスの1.4.2では、「テストケースの設計」というタイトルで、テストケースのつくりかたについて丁寧に書いてあります。
実はALTAシラバスの中で私が一番好きな箇所は今回から始まった「1.4.2 テストケースの設計」です。
経験豊富なテストエンジニアがテストを始めたてのテスト担当者にテストのノウハウを丁寧に一生懸命伝えようとしている文章だと感じるからです。
ISTQBのシラバスは「アカデミックに偏りがち」と言われているそうなのですが、少なくともこの『ALTAシラバス 1.4.2』のところはそんなことはないので、テストエンジニアの方は全員読み返すといいんじゃないかなあと思います。
読み返すたびに新しい発見がありますし、1行1行の内容が濃くて好きです。
ということで、今回の本題の「テストケースとは何か？」です。まず、シラバスを確認します。以下、要約したものです。（採番はシラバスの記載順です）
① 目的
② 事前条件（テスト環境、テストのリリース計画、実行前のシステムの状態）
③ テストデータ（入力値と、事前に設定する変数値）
④ 期待結果
⑤ 事後条件
たくさんありますが、大切なものは太字にした、「① 目的」、「③ テストデータ」、「④ 期待結果」の3点です。
ここで、用語集を確認してみます。
こちらも参照ということですので、「テストステップ」も調べます。（灰色のボタンを押すだけです）
テストステップに“test step”と対応する英語が書いていない理由はなんだろう？？
単なる書き忘れかな？
一緒に覚えておきたいのは「テストプロシジャー」という用語です。こちらですが、昔は「テスト手順」と呼んでいたので、テストケース内の「アクション」と紛らわしいものでした。
用語集から抜き出しただけで、いまいちわかりにくいので表にしてみました。「アクション」というのは、「操作手順」のことですが、ハイレベルテストケースの場合や、わざわざ書かなくても期待通りのテストを実行するだろうという場合は書かないこともあります。
表にしても「事前条件の実行前のシステムの状況と、テストデータの事前に設定する変数値」の違いや、「期待結果と、事後条件の違い」などモヤっとしますよね。
「どちらかと言えば……」で使い分けるので良いと思っています。前に、テストプロシジャーをつくるときに事前条件・事後条件を使うと便利でした。
テストケースAとテストケースBを連続して実行するときに、テストケースAの事後条件がテストケースBの事前条件と同じなら、テストケースBの事前条件をセットする手間を省けるためです。
関係を整理してみます。
1つのテストケースに複数のテストステップを持つものや、テストステップにアクションを持たない（わざわざ記載しない）ものもあると思います。
実は、ISO 29119ではテストプロシジャーが違う意味だったりします。
したがって、テスト管理ツールを自作する人でない限りは「まぁ適当に」といったところで、チーム内で意味が統一していれば良いと思います。正確な定義よりも、テストで検討すべき要素を明らかにすることが大切と思います。
≡ JSTQB ALTA試験対策
まず、テスト設計の「学習の目的」を確認します。
1.4 テスト設計
TA-1.4.1 （K2）ステークホルダーがテスト条件を理解する必要がある理由を説明する。
TA-1.4.2 （K4）特定のプロジェクトシナリオに対して、テストケースの適切な設計レベル（ハイレベルまたはローレベル）を選択する 。
TA-1.4.3 （K2）テストケース設計で考慮すべき問題を説明する。
今回の範囲（1.4.2）については、TA-1.4.2を問う問題とします。K4なので、「分析」という深いレベルで使いこなせることを確認するテストとなります。
《問題》
テストケース（TC）について書かれた以下の選択肢で正しいものを選びなさい。
1. ローレベルテストケースのみTCを作成する
2. テスト条件とハイレベルテストケースは同じもの
3. TCにアクション（操作手順）を書くこともある
4. TCに書く「目的」は観測可能なものとは限らない
答えは次回に書きます。
≡ おわりに
今回は、「テストケースとは何か？」でした。
テストケース周りの用語は、まだ揺れがあるようです。
ただ、揺れがあるといっても、「ISTQBでは……」とか「ISO 29119では……」といった標準がどうなっているかを知ったうえで、自プロジェクトのテンプレートを決めると良いと思います。
今回、ALTAテキストの追記はありません。1.4.2についてはまとめて書きます。
次回は「1.4.2 テストケースの設計」の続きです。中編として、「期待結果」について書きたいと思っています。
この記事が気に入ったらサポートをしてみませんか？