48号：エラー・欠陥・故障

≣ はじめに

「ASTERセミナー標準テキスト」の25-27ページについてです。

日本では「バグ」という言葉が、もっとも一般的に使われていると思います。辞書でバグを引くと「コンピュータのプログラムのあやまり」（日本国語大辞典より）と載っています。
これを言葉通りに受け取りますと、まず、「コンピュータの」とありますので、「スマホはどうなんだろう？」ということになります。
「スマホはコンピュータでいいんじゃない？」という合意は得られそうですが、自動車や、冷蔵庫はどうでしょう？　洗濯機はコンピュータでしょうか？？
「細かいなあ。CPUが載っていたらコンピュータだよ」と言う人もいると思いますし、「コンピュータのプログラム」というのは、「演劇や催し物のプログラム」ではない方の「プログラム」つまり「ソフトウェア」のことだよ、と言う人もいるでしょう。

それでは、「仕様書に書かれた設計ミス」は「バグ」でしょうか？

また、「コンピュータのプログラムのあやまり」ということは、どこかにある「あやまり」のことですが、例えば、プレゼンテーション中に、ページ送りをしても何にも反応が無かった時、つまり、ハングアップやフリーズしたときについ言ってしまう、「バグりました」のバグはなんでしょう？？　「バグりました」は「バグ（が顕在化しやが）りました」ということなのでしょうか？

先日、「Outlookで特別な件名があるメールは相手に届かない」という現象についての記事を読みましたが、ハングアップやクラッシュ以外にも、このような、“おかしな現象”も「バグ」と言うと思います。

日常会話であれば、文脈（コンテキスト）が共有されていますから「バグ」という言葉だけで意思疎通に問題が発生することはほとんどないでしょう。しかし、教科書や論文で異なる概念に同じ用語を使用すると、混乱し、読者に誤解を与える懸念があります。
そこで、規格書や技術書や論文では「バグ」というあいまいな用語（あいまいというよりも、多義語と言う方が正確かもしれません）を使うことは滅多にありません。

JSTQBでもバグを、「エラー」、「欠陥」、「故障」の3つの用語に分けて説明しています。
今回は、この3つの使い分けについて書きます。

≣ エラー・欠陥・故障の定義

25ページでは、

エラー（error）：間違った結果を生み出す人間の行為をいう。（ヒューマンエラーのエラーと同じ。）
欠陥（defect）：作業成果物に存在する、要件または仕様を満たさない不備または欠点。
故障（failure）：コンポーネントやシステムが定義された範囲内で要求する機能を実行しないこと。

と定義しています。これはJSTQBで使っている「定義」ですので、覚えるしかありません。
気を付ける必要があるのは、あくまでもJSTQB内の「定義」ということです。つまり、同じ単語でも、別の団体では別の定義の可能性があります。例えば、SQuBOK V2からIEEE 610の定義を書き出してみます。

IEEE Std 610〔IEEE Std 610.12-1990〕の定義

Error：計算された値、観察値若しくは測定値または条件と、真値、指定値若しくは理論的に正しい値または条件との相違
Fault：ハードウェアのデバイスまたはコンポーネントのディフェクト。コンピュータプログラムの間違ったステップ、プロセス、またはデータ定義
Failure：システムやコンポーネントが、指定された要求性能通りに機能を実行することが出来ない状態

なお、SQuBOK自身は、JIS X 0014〔JIS X 0014:1999〕に準拠し、ソフトウェア上にある問題を「障害（fault）」と呼び、その結果として引き起こされる現象を「故障（failure）」と呼んでいます。

これだけでもややこしいのに、JSTQBではさらに、

不正（anomaly）：ドキュメント、標準、知見、経験から逸脱するあらゆる状態

もあります。「不正」と漢字で書いていても「アノマリー」と読む人が多いように思います（一般に、日本語で「不正」というと、「不正を働く」というように、「正しくない行い」、「正義に反する」といった意味となるからだと思います。ソフトウェアテストの文脈では「期待していた結果と異なる」程度の意味を持ちます）。

ごちゃごちゃと書きましたが、簡単に言うと、defectが原因で発生した現象が故障（failure）で、原因は分からないが「（期待値と異なっていて）何かが間違っていそうなもの・こと（＝偽陽性（FALSE-fail result）を含む）」を不正（anomaly）と呼びます。

言い換えると、テストをしていて「あっ。なんか変」と思ったものは全て不正（anomaly）です。不正のうちでソフトウェアに問題のもととなる欠陥（defect）が存在すれば、その不正（anomaly）は、それ以降、故障（failure）と呼ばれるようになります。もしも、テスト担当者の勘違い（＝偽陽性）だった場合は、「仕様通り」や「テスト実行時のミス」等と呼ばれることになります。

そうそう。failureは、fail+ureです。failはテスト結果のところに書くpass/fail/blockのfailで、「失敗する」という動詞です。そして、動詞に接尾語である「-ure」を付けることで「失敗/不成功/故障/機能不全」という名詞にしているわけです。cult（耕す）に「-ure」を付けて、culture（文化）です。
名詞化する接尾語には他にも「-ture」があります。cap（つかまえる）に、「-ture」を付けて、capture（捕獲、キャプチャー）です。
要するに、「-ure」や「-ture」は、日本語でいうと「ｰこと」にあたります。先の「捕獲」を「つかまえること」と言っても同じ意味です。

うんちくはさておき、色々な用語が出てきたので、表にしてみます。

ソフトウェアテストの世界ではISTQB/JSTQBの用語が使われることが多いですから、まずは、エラー（error）・欠陥（defect）・故障（failure）という用語を覚えてしまいましょう。

とはいっても、私も故障（failure）については違和感があります。
故障を辞書で引くと、「機械、からだなどの一部に異常が起こって、機能が損なわれること。動きが止まったり、狂ったりすること。こわれること」とあります。
短く言い換えると「故障は、一部が壊れて機能が損なわれること」となりますが、ソフトウェアの場合は、使っているうちに壊れるわけではなく、購入（入手）したときから欠陥は持っているからです。

つまり、defectとfaultの違いについては、

defect：初めから欠陥がある（設計問題）
fault：経年劣化や摩耗などによってあとからできた欠陥（購入直後は無い）

です。
欠陥については、faultとdefectをハードとソフトで使い分けることによってスッキリするのですが、ハードウェアのfailureに対応する単語がソフトウェアにはありませんので「故障」という言葉がソフトウェアに対して使われているようで、スッキリしません。セミナー時に受講生から何度も「故障なんていいません」と言われました。「では、何と言っていますか？」と聞くと「テスト中ならバグで、ユーザー先なら不具合かなあ」と言われることが多いです。

「バグ」、「障害」、「不具合」という用語ですが、修正するという文脈で使われるときには、defectの言い換えと思って構いません。各組織で自分たちの言葉を定義しても良いでしょう。（一時期、「バグ」と言われると気分悪いから「ドラゴン」と呼ぼう！　なんてネタ？　がありました）

そもそも、日本語は現象を表す単語と、現象の元になっているものとの区別が曖昧なのかもしれません。

さて、26ページにエラー・欠陥・故障の関係を図にしたものがあります。

人が何か失敗をして、欠陥を作りこみ、それが故障として顕在化する図です。この図を隅から隅まで順を追って眺めて、エラー・欠陥・故障の違いを腹落ちさせることをお勧めします。

≣ 対応の違い

私は、このスライドが好きで、セミナーの時にも割と時間を取って説明しています。似た概念に違う言葉を割り当てる意味を理解することはとても大切だと思うからです。

まずは、

故障への対応：　ユーザーの今起きている困りごとをなくす。若化（リジュビネーション：リブート等）や回避策の提示も有効な対応である。ただし、故障の原因は直っていないため、別のユーザーで同じ故障が起こる。

です。

ソフトウェアをテスト中に変なことが起こったら、まずは、簡単に再現できそうかどうかを考えて、ハングアップのように、滅多に起こらず、再現頻度が低そうだと思ったら、現場を温存し、開発者に連絡し、原因究明を行うと思います。（殺人現場を温存して名探偵に見てもらうのと似ています）

呼ばれた開発者は、故障発生中のマシンにリモートログインしたり、特別なポートからTTY端末で入ったり、それもできなければ、特別なボタンの組合せを押して、割り込みを発生させてメモリダンプを取ったりします。（昔は特別なシグナルをコンピュータに送って、プリンターに、16進数を何百ページもプリントしていました）

でも、これは、テスト時だけにしましょう。実運用中（お客様先で実稼働中）のときには原因究明よりも「ユーザーの今起きている困りごと（例えば業務の中断）をなくす」ことのほうを優先します。ハングアップしていて、ディスクのアクセスランプがチカチカしていなければ、リブートしてみるのも一つの手でしょう。

ディスクのアクセスランプが点滅していたら、消えるまで待ちましょう。（重要な情報を編集中だった場合には、一晩くらい待ったほうが良いこともあります）

若化（“じゃっか”と読みます）は辞書にも無いですし、聞きなれない言葉かもしれません。（老化の対義語と考えると良いかもしれません。老化の正しい対義語は「発育」ですが。）

英語ではrejuvenationと言いますが、「リジュビネーション」で検索すると“若返り”関係の美容ページがヒットします。

分かりやすく言えば、おかしくなる前に戻してしまうということです。（厳密に言えば、全てが昔に戻る“若返り”ではなく、何かのポイントのみが“若化”するということですので、若返りと若化は少し意味が異なります。若化は時間を戻すのではなく、対象の一部を若い方向に変化させることです）
MacにはTime Machineというバックアップ機能があります。これは、バックアップを復元することで正常だった状態に戻るための機能ですので、若化の一種と言ってよいでしょう。

次は、

欠陥への対応：　欠陥レポート、デバッグ、リグレッションテスト、再リリースを行う。故障の原因は直るが、欠陥の作りこんだ理由には迫っていないため、次のプロダクトで再発したり似た現象が発生する。

です。
リブートして使えるようになって、回避策を取るなどすれば、故障していたユーザーの問題は解決します（そのユーザーは自分が成し遂げたいことを遂行することができるようになります）。

でも、同じソフトウェアを使用している人が他にもいたら、そちらで故障が発生するかもしれません。
発生頻度が低くても、何十万本も使われていたら、故障の連絡がヘルプデスクへ毎日・何度も届くかもしれません。そうするとサポート費用（運用費）がかさみますし、ソフトウェアのみならず、会社の評判も悪くなります。
それは、困るので、故障の原因である欠陥を直します。

最後は、

エラーへの対応：　欠陥を作ってしまった原因を究明し、原因に手を打つことで同種の欠陥を未然防止する。原因の例を以下に示す。
　・ 納期のプレッシャー
　・ 人間のもつ誤りを犯しやすい性質
　・ 経験不足または技術不足（不慣れな技術を含む）
　・ 誤ったコミュニケーション
　・ コード・設計・解決すべき根本的な問題・使用する技術の複雑さ
　・ システム間のインターフェースに関する誤解

です。
欠陥を直せば、そのソフトウェアの問題は完全になくなります。しかし、欠陥を作りこんでしまった原因（失敗を究明して）をつぶしておかなければ、次の開発で同様の欠陥を作ってしまいます。
そこで、欠陥分析を行って、欠陥を作ってしまった原因に手を打ちます。

スライドには、エラーの例が6つ載っていますが、技術力不足はそのなかの1つにしかすぎません。

これらの入門として、『続テストガールRINA（ノービス編）』を読んでいただけるとうれしいです。

≣ 終わりに

ユーザーに対して正しい対応（＝困った現象を消すことを最優先）をするために「故障」という用語があり、他のユーザーで同じ問題が発生しないように再発防止をするために「欠陥」という用語があり、次の商品で似た問題が発生しないように未然防止をするために「エラー」という用語があることについて説明しました。

似た用語に関しては、まとめて違いや背景を調べると覚えやすいと思います。例えば、「リスク」と「ハザード」の違いとか……。