テスト業界ではバグ、つまり問題のことを故障/欠陥/エラーとわけて呼んだりします。
このことが話題に上がっていたので話を書いてみます。
- 言葉の意味
- エラーにより欠陥が埋め込まれ、欠陥が実行されて故障として現れる
- そんなに言葉をわけてなにか嬉しいの？
- 言葉(名前)は共通理解が大事
- じゃあテスターちゃんの人は社内で故障/欠陥/エラーとわけて話してるんですか？
言葉の意味
それぞれの言葉の意味からです。
故障
コンポーネントやシステムが定義された範囲内で要求する機能を実行しないこと。
JSTQBの用語集からです。難しい言葉が並んでいますね(笑)
簡単に説明すると、アプリを動かした結果、プロフィールが表示されないとかメッセージが送信できないといった「発生した問題(出来事)」を指しています。
ちなみに期待結果との相違を不正(アノマリー)と言ったりしますが今回は置いておきましょう。余計にややこしくなりそうです(笑)
欠陥
作業成果物に存在する、要件または仕様を満たさない不備または欠点。
欠陥は、例えばプログラムで (x < 10)と書くところを(x < 9)と書いてしまったとか、エラーの時の処理を書き忘れたといったような「埋め込まれている問題」を指しています。
その問題の部分(欠陥がある部分)が実行されるまでは表に出てこない――つまり故障という出来事として現れることはありません。
エラー
間違った結果を生み出す人間の行為。
この言葉がテスト業界の人と開発の人で使い方が一番異なる言葉な気がします。
ここは説明そのままです。例えば業務知識が不足していたので間違った設計をしてしまった、前の人が「ヨシ！」と言ってたので僕も「ヨシ」としてしまった、などでしょうか。
開発の人が「エラーが発生してる」といった場合は「僕は寝不足で寝不足で間違ったことをしています」と自己申告をしているのではなく、「故障が発生した」になりそうです。
エラーにより欠陥が埋め込まれ、欠陥が実行されて故障として現れる
まとめると上記のような流れになります。
プロセスがいい加減だった結果、うっかりプログラムを書き損じてしまって、実行したら動かなかった。
こんな感じでしょうか。
欠陥と故障は原因(欠陥)と結果(故障)の関係であり、エラーと欠陥も原因(エラー)と結果(結果)の関係にあります。
また、１つの欠陥から複数の故障が起こる場合もあります。
例えば、様々な場所から呼び出される共通のプログラムで書き損じがあった場合です。
この場合、テストをすると
「機能Aのレスポンスが来ない！」
「機能Bはnullって表示されている！」
このような問題（出来事）を観測できます。故障ですね。
それぞれの出来事について我々はバグ票(この場合故障票と呼ぶの？呼ばない)を記載します。
そして、共通するプログラムを修正するとどちらの故障も発生しなくなります。
別々の出来事(故障)が、共通の欠陥から発生することがあるということです。
同様に、1つのエラーから複数の欠陥が埋め込まれる場合もあります。
そんなに言葉をわけてなにか嬉しいの？
ふわっとした概念に「名前」を付けることによって扱いやすくなります。
名前を付けることで形を持つといったところでしょうか。古くから我々は、様々なことに名前を付けて扱えるようにしてきました。
では、今はひっくるめて「バグ」と言ってみましょうか。
例えば。
レスポンスが悪化する「バグ」があります。
ユーザーからも「バグ」の問い合わせが複数あります。CSからどう対応したらいいか聞かれています。
けれどこの「バグ」の原因となるプログラムの「バグ」がわかりません。
はやくこの「バグ」に対応しなければなりません。
そこで我々テスターはこの「バグ」に対応するために、CS/開発/企画含め緊急の「バグ対応ミーティング」を開くことにした。
さて。
この状況では、レスポンスが悪化する出来事――「故障」が発生しています。
ユーザーからも問い合わせがあって、CS側としては「ユーザーに返答する、故障への対応の方法」を求められています。
ただ開発で調べたけれどレスポンス悪化という「故障」がどこの「欠陥」によって引き起こされているかわかりません。
その状態で、我々テスターは緊急のミーティングを開くのですが、この緊急ミーティングは「何に対応したい」ミーティングでしょうか。
欠陥をどう直すか？いやいやその前に欠陥を見つけるためにどういったテストをすればいいか？
というよりは、まずは「今発生している出来事（故障）」に対応したいのです。
そのために、例えば開発側ではスケールアウト(サーバーの台数を増やす）といったサーバーサイドの対応でしのげるのか、テスター側ではスリープにすれば直る？wifiをつなぎ直せばいい？といったクライアント側での回避策（ワークアラウンド）で対処できるのか、それとも直近の変更をリバート（元に戻す）のか……といった故障への対応方針が優先されます。
このように「名前」を付けてあげることで「何を指しているか」がわかりやすくなり対応しやすくなります。
言葉(名前)は共通理解が大事
エンジニア的に言うと、言葉は通信プロトコル(通信するための約束事)です。
異なると「何を指しているかがわかる」という利点が失われます。
そこでテスト界隈では基本的にはJSTQBをベースとしていることが多いです。
これによって、共通の理解で話ができます。
https://jstqb.jp/syllabus.html
じゃあテスターちゃんの人は社内で故障/欠陥/エラーとわけて話してるんですか？
話してません。
僕はバグ、またはissue(イシュー)と言っています。テスター以外には伝わらないからです。
先ほど書いた通り言葉は共通理解が大事なのです。
例えば開発の人と話すときに「エラーを防ぐプロセスを考えたい」といった場合は意図が伝わりそうでしょうか？
それよりなら「うっかりミスを防ぐプロセスを考えたい」と言ったほうが伝わりそうですね。
ですがこれがテスターだけのミーティングではどうでしょうか？
こちらなら問題なく意図が伝わりそうです。
通信プロトコルは、受け取る相手によって変更する必要があります。
受け取る相手が、こちらの意図を正しく理解できるように、相手に合わせた言葉選びをする必要があるということです。
