試験に出ないJSTQB　ALTA

あきやま🍠 @akiyama924

最後は、 ④適用すべきテスト技法が明確であること こちらは、議論が分かれるところかもしれません。 「金槌を持つ人には全てが釘に見える」という諺があります。 「適用するテスト技法が与えられると、テスト対象はその技法で解くべきものに見える」ということです。

あきやま🍠 @akiyama924

テスト分析の時に、たとえば「Nスイッチテスト技法」が与えられたら、テスト分析対象のソフトウェアは状態遷移に見えてしまい目が曇って（他の見方が出来なくなって）しまうかもしれません。テスト技法はテスト設計フェーズでしっかり考えるほうが、良さそうです。 解説おしまい。

あきやま🍠 @akiyama924

【試験に出ないALTA】 問題107 テスト条件について正しい指摘では【ないもの】はどれですか。

あきやま🍠 @akiyama924

選択肢が途中で切れて読みにくい人へ ①さまざまな詳細度合いで定義することが望ましい ②プロダクトリスクから識別されることは無い ③通常、テストされるアイテムに固有である ④カバレッジを十分なものにすることができる

あきやま🍠 @akiyama924

問題107の答えと解説です。 正解は、2の「プロダクトリスクから識別されることは無い」です。 正答率は56%です。 出題の意図は、「テスト条件」というテスト分析の最重要アウトプットの理解を深めるためです。

あきやま🍠 @akiyama924

解説です。まずは、 ①さまざまな詳細度合いで定義することが望ましい この次の問題と関係しますがテスト対象やテスト目的を漸進的に分解し、さまざまな詳細度で定義することがポイントです。理由は次問の解説で明らかになる予定です。

あきやま🍠 @akiyama924

次は、 ②プロダクトリスクから識別されることは無い 私はリスクベースは嫌いですが、最重要３リスクについては識別しテスト条件を見つけるべきと考えています。最重要３リスクとは、健康・財産・環境の３つのリスクです。

あきやま🍠 @akiyama924

健康・財産・環境の３つのリスクは必ず対処する必要があります。対処しなければニュースになりますし、下手をすると会社が倒産します。 健康リスクには生命リスクも含みます。健康と財産の両方を脅かす問題に火災があります。

あきやま🍠 @akiyama924

たとえば、車のエンジンのソフトウェアにバグがあって、極少ない発生頻度ながらオーバーヒートして車は止まり、エンジンが壊れるとします。 何十万台も売れば極少ない発生頻度でも発生します。そして、発生した時には乗員を危険にさらし、エンジンが壊れ財産を失わせるとしたら許されません。

あきやま🍠 @akiyama924

環境リスクも同様で、フォルクスワーゲンの問題で学びました。 重要なので繰り返しますが『健康・財産・環境の３つのリスクは必ず対処する必要があります』です。 ですから、この３重要リスクについてだけはプロダクトリスクを識別し、アセスメントし、テストすることでリスクの軽減を図ります。

あきやま🍠 @akiyama924

そして、 ③通常、テストされるアイテムに固有である やはり、テスト対象からテスト条件を出すのがテスト分析の中心です。

あきやま🍠 @akiyama924

最後は、 ④カバレッジを十分なものにすることができる テスト条件を出し尽くすことでテストをやりきることにつながります。 解説おしまい。

あきやま🍠 @akiyama924

【試験に出ないALTA】 問題108 具体的テストケース（CTC＝concrete test case）と論理的テストケース（LTC＝logical test case）の説明で【誤っているもの】はどれか。

あきやま🍠 @akiyama924

選択肢が途中で切れて読みにくい人へ ①CTCは優れた再現性を提供する ②CTCはテスト担当者の創造力を制限する傾向にある ③LTCはCTCよりも優れたカバレッジを提供しない ④LTCはテスト対象に関するガイドラインを提供する

あきやま🍠 @akiyama924

問題108の答えと解説です。 正解は3の「LTCはCTCよりも優れたカバレッジを提供しない」です。 正答率は71%と狙いどおりです。w 出題の意図はテストを作るコツだから。なんか、単なるコツなのに、こうしなければならないと思っている人が多くてびっくりです。

あきやま🍠 @akiyama924

解説です。 まずは実際に起こったことから。 それは20年以上昔のこと、とあるバグがテストをすり抜けて市場に出て大騒ぎになったことがありました。

あきやま🍠 @akiyama924

どんなバグかというと、「13文字以上の長さのパスワードを設定できない。エラーとなる」というものでした。 パスワードの長さの仕様は「4文字以上、15文字以下」でした。

あきやま🍠 @akiyama924

早速テスト担当者を呼んで「テスト漏れ？」と聞きました。 そしたら、テスト漏れでは無いというのです。

あきやま🍠 @akiyama924

テストケースを見ると「4文字以上、15文字以下のパスワードを3つ作ってパスワードが設定できるかについて確認をする事」と書いてあります。

あきやま🍠 @akiyama924

詳しく話を聞いてみると、このテスト担当者は、こう書けば4文字と15文字と間の9文字の3つのパスワードを作ってテストをするのが当然と思っていたと言うのです。書かなくても分かるだろうと。

あきやま🍠 @akiyama924

ところが、実際にテストをした人は4文字、5文字、6文字のパスワードでテストをしたと言うのです。 これでは「13文字以上のパスワードを設定できない」というバグは見つからないわけです。

あきやま🍠 @akiyama924

さて、この実例の 「4文字以上、15文字以下のパスワードを3つ作ってパスワードが設定できるかについて確認をする事」が、論理的テストケースに当たります。

あきやま🍠 @akiyama924

また、このテスト担当者がもし、さて、この実例の 「4文字、9文字、15文字のパスワードを作り、この3つのパスワードが設定できるかについて確認をする事」と書いていたらそれが具体的テストケースになります。 以上を踏まえて選択肢を見ていきましょう。