第292回： 「ALTAのテキストをつくろう」47 （エラー推測／後編）
◀前の記事へ 次の記事へ▶︎
≡ はじめに
前回は、「3. テスト技法」の「3.3 経験ベースのテスト技法」の「3.3.1 エラー推測」の定義について書きました。
エラー推測の定義とは、「「エラー、欠陥、故障の発生」の経験とテストの能力によりテストを行う方法」のことです。「2,451文字もあって結論は35文字かよ。」という声が聞こえた気がしますが、そんな回もあるさー。
ただ、真面目な話、「エラーしか推測しない（してはならない）」と思い込んでいた私のような人にとっては「欠陥と故障についても推測して良い」という情報は、思考のスコープを３倍に広げてくれるからお得だと思うのです。
ところで、SQuBOKでは、エラー推測は「経験ベースのテスト」ではなく「フォールトに基づいたテスト」に分類されています。
まだ定義が揺れている用語なんですね。
最初っから知っていた人にとっては「ふーん」だったと思いますが、そんな回もあるさー。（2度目）
ちょっと前回の捕捉をすると、ALTAシラバスには「エラー・欠陥・故障」のほかに、「故障モード」（failure modes）も出てきます。
“In addition to being used as a test technique, error guessing is also useful during risk analysis to identify potential failure modes.”（JSTQB訳： エラー推測は、テスト技法として使用されるだけでなく、潜在的な故障モードを識別するためのリスク分析時にも役立つ）
でも「故障モード」の話は、シラバスの他の箇所に出てこないので、忘れて大丈夫だと思います。
心配な人は以下の用語集のFMEAあたりを抑えておくと良いと思いますが、「リスクの識別と分析(故障モードの識別と、発生防止策の試み)を行なう体系的なアプローチ。」と言われてもなあという感じだと思います。
FMEAについて知りたい人は久米先生の『設計開発の品質マネジメント』を読みましょう。他の本のFMEAは読まないか、読んでしまった人は忘れましょう。故障モードのところだけ引用します。
FMEAの基盤は、故障モード（failure mode）の概念にある。故障モードは、故障そのものではなく、故障をもたらす不具合現象の様式分類である。一方、故障モードは故障原因そのものではなく、故障原因からもたらされた不具合事象の様式分類でもある。
故障モードの例としては次のようなものがある。
断線、短絡、固着、表面あれ、漏れ、外れ
ゆるみ、つまり、折損、割れ、欠損、など
ーーー 略 ーーー
原因（故障モードの原因） → 故障モード → 故障（故障モードの影響）
つまり、「製品の故障は千差万別で予測不可能だけど、一つひとつの構成要素をみたら共通に考えうる故障モードがあるでしょう？」という考え方です。いろいろな本に嘘のことが書いてあるから気を付けてくださいね。正しい方法でFMEAをしないと効果が出ないので。（ソフトウェアエンジニアの人がFMEAを行うことは滅多にないと思いますが）
正しい故障モードの概念が分かると、ISTQBの用語集の「リスクの識別と分析(故障モードの識別と、発生防止策の試み)を行なう体系的なアプローチ。」というFMEAの説明中にある「故障モード」の概念のピントがずれているって分かりますよね。
なお、にしさんがよく言っていた“不具合モード”もね。“故障モード”じゃないですよ。ピンポイントにテストするための技術です。ちゃんと考えて、まとめておいた方がいいのになあ……。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「3.3 経験ベースのテスト技法」の「3.3.1 エラー推測」について書きます。
≡ 前回の復習
以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、選択肢4の「上記の全て」が63.3%と最も多く、正解も4です。投票数は30票と少し少な目（前回は44票なので、前回の2/3程度）、正解率も2/3弱なので、「改めて聞かれると迷うなあ」という問題だったかもしれません。
ISTQBの定義はこうなっているというだけの問題ですので、解説はありません。
受験する人は気を付けてください。
前回の復習は以上として、今回のnoteのテーマに移ります。
≡ エラー推測の適用、制限／注意事項、カバレッジ、検出できる欠陥の種類
シラバスの記載量がブラックボックステスト技法と比較して半分以下なので中編と後編に分けることなく一つで行きます。
■ エラー推測の適用
「エラー推測の適用」について、シラバスの全文を引用します。
エラー推測は、主として、統合テストおよびシステムテスト時に実行するが、すべてのテストレベルで使用できる。この技法は、多くの場合、他の技法と組み合わせて使用する。また、既存のテストケースの範囲を拡大するのに役立つ。エラー推測は、ソフトウェアを新しくリリースするときに、より厳密な手続き化されたテストを開始する前に、一般的な欠陥をテストする場合にも効果的に使用できる。
ひと言で言えば「エラー推測は、どこでも使う」です。
■ エラー推測の制限
「エラー推測の制限」について、シラバスの全文を引用します。
エラー推測には、次の制限と注意事項が適用される。
● カバレッジを評価することは困難であり、テストアナリストの能力と経験に応じて大きく異なる。
● テスト対象のコードの種類に共通して埋め込まれる欠陥の種類に精通している経験を積んだテスト担当者が使用する場合に最適である。
● 一般的に使用されているが、文書化しないことが多く、他の形式のテストに比べて再現性が低いことがある。
● テストケースは文書化される場合があるが、作成者だけが理解して再現できる形である。
ひと言で言えば「エラー推測の制限は、それを使うテストアナリストの能力と経験に左右されるし、文書化は難しい」です。
■ エラー推測のカバレッジ
「エラー推測のカバレッジ」について、シラバスの全文を引用します。
欠陥分類法を使用すると、テスト済みの分類アイテムの数を分類アイテムの総数で割ってカバレッジをパーセンテージで表すことで判定できる。欠陥分類法を使用しない場合は、テスト担当者の経験と知識や利用可能な時間によりカバレッジが制限される。この技法で検出できる欠陥の量は、テスト担当者が問題のある領域を対象にできる能力に依存して異なる。
「欠陥分類法」は、例えば、ODC(直交⽋陥分類： Orthogonal Defect Classification)が有名ですが、こちらでカバレッジを求めるなら、Source属性でやる方法があるよということでしょう。
ODCは、『ソフトウェア不具合改善手法 ＯＤＣ分析』という書籍で学ぶか、ODC分析研究会の発表資料で学ぶのが良いと思いますが、まずは、森さんの『ODC(直交⽋陥分類) 概説』で全体的な話を頭に入れておくと理解が楽になります。
英語の原点である『Orthogonal Defect Classification v 5.2』を読むのが確実という話もありますが、私は概要を知ってからのほうが良いんじゃないかなと思います。
色々と書きましたが、ひと言で言えば「エラー推測のカバレッジは、きちんと測定できない」です。
■ エラー推測の検出できる欠陥の種類
「エラー推測の欠陥の種類」について、シラバスの全文を引用します。
典型的な欠陥は、通常、特定の欠陥分類法で定義されているか、テストアナリストが「推測」する。これらの欠陥は、ブラックボックステストでは検出されないことがある。
ひと言で言えば「エラー推測の欠陥の種類は、それを使うテストアナリストの能力と経験に左右される」です。
ということで、エラー推測の適用、制限／注意事項、カバレッジ、検出できる欠陥の種類は、「それを使うテストアナリストの能力と経験に左右される」です。
これが何を意味するかと言えば、「エラー推測技法で成果をだしたいならテストの能力と経験を上げなさい」ということです。
逆に言えば、「能力も経験もなければ、エラー推測テストをしても成果は出ない」ということです。
≡ JSTQB ALTA試験対策
いつものことですが、まずは、「学習の目的」を確認します。（同じ範囲なので、前回と同文です）
TA-3.3.1 （K2）経験ベースのテスト技法の原則と、ブラックボックステスト技法および欠陥ベースのテスト技法と比較した場合の長所と短所を説明する。
TA-3.3.2 （K3）与えられたシナリオから探索的テストを識別する。。
なぜ、TA-3.3.1 とTA-3.3.2 の二つを引用したかと言いますと、エラー推測に関するものがないからです。
「1. エラー推測は試験に出ない」、「2. 経験ベーステスト技法の原則のひとつとしてTA-3.3.1が適用されて、K2レベルの問題が出る」、「3. 探索的テストと同様に考えて、TA-3.3.2が適用されて、K3レベルの問題が出る」のどの解釈が正しいのでしょうか？ （K2：理解、K3：適用、K4：分析）
わたしはK2レベルだと思います（K3レベルの問題は作りにくいから）。
《問題》
エラー推測技法について説明した以下の文で誤ったものを選びなさい。
1. 検出できる欠陥は経験のみに依存する
2. 欠陥分類法を使用してカバレッジを判定できる
3. ユニットテストでも使用することがある
4. テストケースは文書化される場合があるが、作成者だけが理解して再現できる形
答えは次回に書きます。
≡ おわりに
今回は、「エラー推測の適用、制限／注意事項、カバレッジ、検出できる欠陥の種類」がテーマでした。
昔「これはテスト技法なんだろうか？」と悩んでいました。technique, technology, skillではなくArtなんじゃないか？と。
でも、“Art”の元になったのラテン語は“Artis”であり、その語源はギリシャ語の“τεχνη（テクネー）”だそうです。
つまり、Artはそもそも芸術よりむしろ技術を意味しているそうで、、、。もう、そんなことは、どうでもいいかと思いました。
大切なことは、エラー（error/defect/failure）の知識をテストに使うこと、使うときにはテスト技術そのものに対する知識と能力も必要なこと。
さて、次回は、「3.3.2 チェックリストベースドテスト」です。こちらは1回で終わる予定です