バグや欠陥といった言葉の整理

QAの仕事のひとつとして大事なものに、ソフトウェアやサービスが期待と同じ動きをしていない事象を見つけたら報告して直してもらうことがあります。また、この様な事象を分析して原因を理解したり、再発しないようにしたりすることもあります。この事象は「バグ」「障害」「不具合」「欠陥」といったさまざまな用語が使われます。

この用語は、標準ごとに微妙に言い方がちがう場合があるため、「どの用語が正しいんだ！」というような議論をしても収集つかないと思います。

私のおすすめは、段階ごとの意味を理解してしまうことです、用語は、標準を参考にしていいと思いますが、最終的には、各組織で定義すればいいと思います。

では、段階ごとの意味としてどういうものがあるかを書いていきます。

1段階：期待結果と実際の結果が異なる

テスト実行したときに、「あれ、これだめじゃん」ってなってしまうときのことです。例えば、本来はサービスでデータの登録ができなければならないのに、登録がされなくなってるとか、画面が真っ白になってしまうとか、そんなときのことを指します。

ニュースで「システム障害のため振込ができなくなっています」と報道される様な事象はこの段階に相当します。

IEEEとISTQB、ISOの用語定義を記載しておきます。

Error(エラー、誤り)
「計算、観測、または測定された値または状態」と、「正しい、仕様化された、または理論的に正しい値または状態」との差異

IEEE Std 610.12-1990(R2002): IEEE Standard Glossary of Software Engineering Terminology, IEEE Computer Society

Anomaly（不正）
要求仕様、設計ドキュメント、ユーザドキュメント、標準など、または知見、経験から逸脱するあらゆる状態。レビュー、テスト、分析、コンパイルをする中で検出できるが、それだけにとどまらず、ソフトウェアプロダクトや該当するドキュメントを利用するときに検出できることもある。(After ISO 24765)

ISTQB Glossary 

Incident
anomalous or unexpected event, set of events, condition, or situation at any time during the life cycle of a project,product, service, or system.（湯本訳：プロジェクト、プロダクト、サービス、またはシステムのライフサイクル中の任意の時点における、不正または予期しない、イベント、イベントのセット、状態、または状況。）

ISO/IEC/IEEE CD 29119-1:2020(E)

2段階：ソフトウェアが正しく機能しない

1段階で期待と異なっている際に、ソフトウェアが問題を起こしたために異なってしまっているときのことです。例えば、本来はサービスでデータの登録ができなければならないのに、登録がされなくなってるが、それはなぜかというと、本来はプラスの数字が計算結果に入らないと登録ができないのが、マイナスの値が算出されたために登録ができないといった場合です。

1段階と2段階は全く同じ事象を指す場合もあります。1段階で計算結果が期待と違うという事象があったが、2段階では、ソフトウェアが計算結果は10と出力するはずが11と出力されていると言った場合は、わざわざ両方の段階を分ける必要もないと思います。しかし、1段階の事象は2段階で対象のソフトウェアとは別のことが起因してることもあります。

この段階を分析すると経験ベースのテストに役立てることができます。どういうP-Vを使うとどんな事象が起きたって整理して探索的テストやチェックリストベースのテストに活用します。

IEEEとISTQB、ISOの用語定義を記載しておきます。

Failure（故障）
正しくない結果

IEEE Std 610.12-1990(R2002): IEEE Standard Glossary of Software Engineering Terminology, IEEE Computer Society

Failure（故障）
コンポーネントやシステムが定義された範囲内で要求する機能を実行しないこと。(After ISO 24765)

ISTQB Glossary 

3段階：ソースコードの中のミス

2段階のソフトウェアが正しく機能しないときに、デバッグして修正しますが、デバッグして明らかにしたコードのミスが該当します。初期化し忘れてたとか、変数名が間違ってたとか、分岐条件が足りないとか、そんな感じです。

ソフトウェアの内部構造に着目してテストをする場合は、この段階の分析が役立ちます。また、どういうたぐいのミスをするのかを次の4段階とセットで分析することで改善活動にも使えます。

タイトルには「ソースコードのミス」と書きましたが、仕様書や設計書の記載間違いもこの段階に該当します。

IEEEとISTQB、ISOの用語定義を記載しておきます。

Fault（障害）
正しくないステップ、プロセス、またはデータ定義

IEEE Std 610.12-1990(R2002): IEEE Standard Glossary of Software Engineering Terminology, IEEE Computer Society

Defect（欠陥）
作業成果物に存在する、要件または仕様を満たさない不備または欠点。（After ISO 24765）同義語　バグ（bug）, フォールト（fault）

ISTQB Glossary 

4段階：コードを書いた人の勘違いや思い込み

ソースコードの記述ミスはなんでしたのか？がこの段階です。タイプミスしてるとか、別の機能で使っている変数が同じものだからそのままコピーしたら該当のモジュールではちょっと名称がちがったとか、以上と超を読み違えたとか、仕様書には記載がないけど、よかれと思って追加したエラーハンドリングの戻り値が利用する側のモジュールでは想定していない値だったため対応できなくなったとか、いろいろあると思います。

この段階も3段階と一緒でコードに限定されません。仕様書や設計書を書いた人の行為としても用いられます。

ここの分析は、ふりかえりのときに話し合ったり、その後の改善活動に使われます。

IEEEとISTQB、ISOの用語定義を記載しておきます。

Mistake（間違い）
正しくない結果を作り出す人間の行為

IEEE Std 610.12-1990(R2002): IEEE Standard Glossary of Software Engineering Terminology, IEEE Computer Society

Error（エラー）
間違った結果を生み出す人間の行為。（ISO 24765）同義語　誤り（mistake）

ISTQB Glossary 

まとめ

ISTQBはISO24765(ISO/IEC/IEEE 24765:2017 システムとソフトウェアエンジニアリング—用語, 語彙)をベースにしています。（対応するJIS規格はなさそうです）IEEEの定義は古いので現在はあまり参照されないかもしれないです。

ということで、英語とそれに割り当てた日本語訳も、いろいろあるのがわかると思います。もっと調べればいろいろあるかもしれませんので、知ってる人は情報ください。

なので、どれが正しいとかいってもよくわからなくなるのであまり議論してもしょうがないです。（ただし、JSTQBの試験を受ける場合はISTQBの用語を覚えておかないと試験に出るので注意が必要です）

ということで、再掲しますが、4段階あることを理解した上で、どの言葉を割り当てたか？って考えてほしいです。 以上

今回のカバー画像は、翔泳社のJSTQB教科書（2018）を執筆したときの挿絵に使う画像の元になった私のお絵描きです。

参考
ISTOBの用語集（日本語）