試験に出ないJSTQB　ALTA

あきやま🍠 @akiyama924

これを故障モードと呼びます。 故障モードも定義を久米均先生の『設計開発の品質マネジメント』という本から引用します。 「故障モードは、故障そのものではなく、故障をもたらす不具合事象の様式分類である。故障モードの例としては次のようなものがある。断線、短絡、固着、表面あれ、漏れ、外れ、

あきやま🍠 @akiyama924

（続き） ゆるみ、つまり、変形、折損、割れ、欠損、など」 どうでしょう？ なんとなく故障モードのイメージが掴めてきましたでしょうか。 さて、それではここで、ハードウェアでは故障モードのアイデアがうまくいくのにソフトウェアではFMEAがうまくいかない理由を考えてみます。

あきやま🍠 @akiyama924

ハードウェアでFMEAがうまくいくのは局所的に故障モードを考えてうまくいくからだと思います。 例えば「ゆるみ」という故障モードは、石油ストーブの石油タンクのフタに適用出来ますが、フタの「ゆるみ」が他に影響することは考える必要がありません。

あきやま🍠 @akiyama924

フタを見たらそれが、石油タンクでも、ペットボトルでも、ピクルス容器でも何でも、フタがゆるんでいることで起こる故障をフタの周りだけで考えればいいのです。石油が漏れる、ジュースがこぼれて鞄がジュースまみれになる、ピクルスの匂いが冷蔵庫に充満するもしくはピクルスがカビるなどなどです。

あきやま🍠 @akiyama924

ソフトウェアで同じ事をしようとしても上手くいきません（さんざんやってさんざんな目に遭いました）。 『回線の負荷が高く「輻輳」している時にタイムアウトするとハングアップする』という現象があったとします。回線がテストアイテム、輻輳が故障モード、ハングアップが故障ですよね。

あきやま🍠 @akiyama924

でも、回線が輻輳するという故障モードを見つけても、輻輳の結果何が起こるかパターンが多すぎて知恵を蓄える事が出来ません。正確には蓄えても次の製品の設計時に役立ちません。 影響が局所的でなく、影響がどこに現れるかソフトウェアの場合は予想出来ないからです。

あきやま🍠 @akiyama924

ということで問題に戻りますと、「火災」は故障で、「短絡」は故障モードで、「ホコリと湿気による電導」は（短絡の）原因で、「プラグとコンセントの隙間」は（ホコリが溜まる）原因です。 解説おしまい。

あきやま🍠 @akiyama924

【試験に出ないALTA】 問題137 欠陥レポートに備えるべき特性では【ないもの】はどれか。

あきやま🍠 @akiyama924

問題137の答えと解説です。 正解は4の「主観的」です。 正答率は79%と高かったです。 出題の意図は、テスターにとってインシデントレポートは活動成果物ですから常により良いものを模索し改善すべきだからです。

あきやま🍠 @akiyama924

解説です。 完全・簡潔・正確はインシデントレポートが持つべき特性の最たる物です。 色々と細かな特性を書くよりも「読み手の身になってインシデントレポートを書きましょう」の一言で十分だと思うのですが、初心者が聞くとそうでもないのかなと思いました。

あきやま🍠 @akiyama924

主観的、悪くないと思います。具体的に書いてみましょう。 以下は、私が見たインシデントレポートの主観的な記録です。 ・こんなバグはお客様が許さない →あなたが許していないだけかと。 簡潔に正確に、 ・説明不足があるかと思います。 →じゃあ遠慮なく書いてね。

あきやま🍠 @akiyama924

ですからインシデントレポートは、事実をストレートに書きましょう。うん、それに尽きます。 解説おしまい。

あきやま🍠 @akiyama924

【試験に出ないALTA】 問題138 欠陥が識別された場合の一般的な欠陥の分類情報の説明として【誤っているもの】はどれか。

あきやま🍠 @akiyama924

選択肢が途中で切れて読みにくい人へ ①多くの場合、重要度と優先度に基づいた分類も行う ②「可能性のある原因」を入力してもよい ③分類フィールドは一般的に詳細に実施するほどよい ④プロジェクトスケジュールへの影響を記載してもよい

あきやま🍠 @akiyama924

【試験に出ないALTA】 問題139 根本原因分析の説明として【誤っているもの】はどれか。 ※　選択肢内では、根本原因をRCと略す

あきやま🍠 @akiyama924

選択肢が途中で切れて読みにくい人へ ①通常はその問題を解決する人（＝開発者）が行う ②RC分析の目的は欠陥を特定し除去すること ③RC絞込のために仮の原因を設定するのはTAが行う ④「不明確な要件」は根本原因の一例である