ソフトウェアの品質を学びまくる2.0

旧ブログからゆっくり移行中です。http://blog.livedoor.jp/prjmng/

JSTQB-ALのお勉強(2周目) ─ 2.5~2.7

 今日は、例題です。うーん、まだ2章か。先は長い。。。
 1周目のエントリはコチラにあります。

www.kzsuzuki.com www.kzsuzuki.com

参考にならない例題

「2.4.2 テストケースの生成」から

テストケースの生成について述べた以下の文章のうち、正しいものの組み合わせを選択肢(A)~(E)から選べ。
(A)1, 2, 3
(B)1, 4
(C)2, 3
(D)2, 3, 4
(E)1, 2, 4
  1. テストベースとテスト条件、テスト条件とテストケースは、それぞれ一対多の関係があるので、あるテストケースに影響を与えるテストベースを1つだけ特定することができる。
  2. 画面を通じた入出力を行うプログラムにおける出力結果とは、画面への出力内容はもちろんのこと、ユーザが直接見ることのない内部のデータや状態を含むことがある。
  3. テストケースは、それが何を根拠に作られたものかがわかるように、テストベースへのトレーサビリティを確保しておく必要がある。
  4. テストケースの期待結果を明確にするテストオラクルは、テストベースの補助ドキュメントの位置づけにある。

 答えは(C)です。
 1.について、テストベース・条件・ケースは、多対多の関係にあります。4.について、テストオラクルはドキュメントとは限りません。前のエントリで、少し詳しく書いております。

www.kzsuzuki.com

「2.5.2 テスト実行」から

テストの実行について述べた以下の文章のうち、正しいものの組み合わせを選択肢(A)~(E)から選べ。
(A)1
(B)1, 2
(C)2, 3
(D)1, 2, 3
  1. テストの実行の順序づけには、「リスクの高いものから先に手をつける」といった戦略的側面の他に、テスト作業の効率化の意味がある。
  2. リスクベースドテストのように分析的なアプローチに加えて、手順・分析・目的を伴わずに場当たり的なアプローチでテストを行うことで、バランスのとれたテストになる。
  3. テストの実行は、初めに定めた順番に従うべきであり、個々のテスト担当者に裁量を与えることでスケジュール面でのリスクを高めるべきではない。

 答えは(A)です。
 2.について、場当たり的にプログラムを操作するテストは、効率的とは言えません。あらかじめテストケース・手順を明確に定めることなく行う探索的テストなどは、十分な経験があって初めて有効なものになります。  3.について、テストを行う順番は、担当者にある程度の裁量を与えることがよいとされます。実際、テストケースと少し外れたところが気になって、寄り道して動かしてみたら欠陥が・・・というのは、珍しいことではありませんよね。

 1.について、『ソフトウェアテスト技法ドリル』で、「FL表」の書き方のtipsが説明されています。

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

『ソフトウェアテスト技法ドリル』 P.108
水準の変更に手間がかかる環境設定などは、FL表の初めの方にまとめておきます。というのは、直交表の性質上、直交表の左に位置する列ほど直後の行における水準の変化が少ないからです。些細なことですが、テストの効率を左右します。

 テスト順が効率に結びつく好例ですね。

「2.6 終了基準の評価とレポート」「2.7 終了作業」から

テストの終了に関して述べた以下の文章のうち、正しいものの組み合わせを選択肢(A)~(E)から選べ。
(A)1, 2
(B)2, 3
(C)1, 3
(D)1
(E)どれも正しくない
  1. テスト終了時点では、計画されたすべてのテストケースが実行済みでなくてはならない。
  2. 摘出された欠陥の、テスト終了時点でのステータスとしては、①原因を調査中である ②改修とテストが完了している ③将来改修することで合意している ④制限事項とすることで合意している のいずれかになるべきである。
  3. テスト作業の終了時点などで作成するテストサマリレポートは、ISO9126で定義されている。

 答えは(E)です。
 1.について、一部のテストケースは、あえてスキップすることがあります。スキップの理由についてシラバスには特に説明がありませんが、たとえばテストケースが誤っていたとか、実環境で実現することが極めて困難な条件が要求されるため、机上での検証とした、などが考えられますね。
 2.について、①原因を調査中である 欠陥がある場合は、終了にならないでしょう。
 3.は、IEEE829ですね。規格が一番苦手です。

ちょっとした言い訳

 基本的にこれらの例題は、シラバスに書いてあることの表現を変えて選択肢にしているだけのものであり、ある意味「機械的」とも言えます。用語の些細な定義に迷い込み、本質を見失っている部分もあるかも知れません。
 もちろん、シラバスをしっかり読めば解けるこの種の問題も出題されると思います。が、アドバンスドレベルの特徴であり、また受験する価値といえるのは、経験から得られる知で解く問題です。はっきりいって受験料2万円って高くてつらいですが、問題作成にかかる手間を考えると仕方ないかと思えるほど、取り組んでいて面白い問題だと思います。

 まあ、落ちたんですけどね。
 落ちたら面白さも半減だよ。