ソフトウェアテストにおける5つの一般的なエラーの管理
テストの専門家の言葉では、「エラー」はしばしば悪役の役割を果たすことがあります。結局のところ、テストの目的はソフトウェアからエラーを一掃することです。
この単純化は便利ではありますが、最終的に誤解を招く恐れがあります。テストの本当の目的は、「製品がその仕様を満たしていることを検証すること」あるいはより広く「顧客のユーザーエクスペリエンスを低下させるような発見があればそれを報告すること」といった、もっと前向きなものです。これらの高いビジネス目標におけるエラーの役割は、もっと繊細なものです。ここでは、テスト中に遭遇する可能性のある、5種類のエラーを紹介します。それぞれが、熟考されて特別な意味合いを持った具体的な管理に値します
1．「本物の」エラー
テスト部門で誰かが「エラー」や「バグ」について話すとき、ほとんどの場合、「要件」と「観察された動作」の間の具体的な相違に焦点が当てられます。事件や事故の発生から、１０秒以内に911のコールセンターに掛かってきた通報電話が常にボイスメールに送られるとしたら、それはエラーです。カナダ在住で入社日が8月の社員が、会社の休暇取得状況レポートに全く含まれていないとしたら、それはエラーです。
しかし、このような単純なカテゴリでさえ明快ではありません。仕様で色名を書き出す必要がある場合、「グレー」と「グレイ」の文字が混在しているのはエラーなのでしょうか？100万ドルを超える顧客からの注文を誤って処理するような UIがあったとして、4,300ドル以上の注文が過去にない場合、それはエラーでしょうか？
簡単に言えば、答えは「はい」です。一般的にテストの専門家は、非現実的なものであっても、これらのカテゴリのすべての指摘事項を報告する必要があります。
すべてを報告するという杓子定規なルール優先主義は、一般に少なくとも2つの利点をもたらします。
1つは、非現実的な入力でのみ頻繁に発生するエラーは、単にまだ観察されていない、より広範なエラーの兆候であることです。たとえば、100万ドル以上の値がすべて誤処理される場合、311.78 ドルのような特定の値もおそらくエラーの対象となります。乱暴な値に関するエラーは、改善が必要な脆弱なコードセグメントにプログラマーの注意を引き付けます。
少なくとも、このようなエラーは仕様の欠陥（英文）を示唆しています。「グレー」対「グレエ」は、「色名」の意味、そして色名がソフトウェアのユーザー エクスペリエンスにどのように寄与するかについて、より注意深く考える機会を要件の専門家に提供します。長音の違いは、ブランディングや機能の重要な部分である場合がある一方で、まったく問題ではない場合もあります。テスターにはそのような決定を下す権限はありません。しかし彼らは疑問を投げかけることには長けています。
2．戦術的なテストエラー
また、テスターの日常的な経験として、テストエラーがあります。テストが失敗してもテスト対象のソフトウェアには問題がないケースです。専門家は、これを「偽陽性 (False Positive)（英文）」または「第1種過誤 (Type I)」のエラーと呼ぶことがあります。テスト外のチームメンバーは、これらのエラーについて聞きたくないでしょうし、ほとんどの場合、聞くべきではありません。
しかし、テストエラーも有益な場合があります。ハードウェアの違いで頻繁に失敗する性能評価や、人間が見ると取るに足らないような不一致を頻繁に訴える自動GUI（graphical user interface（英文））チェッカーは、テストが脆弱であることを示す症状です。テストをよりインテリジェントにする方法や、あるいは簡単に分離できるレベルで適切な不変条件をソフトウェアに組み込む方法はおそらく存在するでしょう。
一般に、テストエラーはテストチームの外部に報告されるべきではありません。しかし、テストチーム内では行動を起こす必要があるかもしれません。
偽陰性 (False Negative)（英文）、つまり第2種過誤 (Type II) のエラーも起こります。しかし、複雑な歴史的および組織的な理由により、存在する不具合がテストでレポートされないケースは、しばしばエラーと見なされません。カスタマーサポートがエラーが発見するということが、そのような複雑な関係を表しています。つまり、ユーザーから指摘されるまで判明しなかった不具合についてサポート部門が報告を受けることはよくあります。これは確かに第2種過誤のエラーです。
サポート部門は一般に、そのような報告を検証し、製品の意思決定者に伝えるように訓練されています。しかし、これらの指摘事項をテスト部門または品質管理 (QC) 部門に伝達するように組織ぐるみで取り組んでいるところはほとんどありません。一般的な組織では、サポートから製品へのコミュニケーションチャネルは存在しますが、サポートからQCへのコミュニケーションチャネルは存在しないのです。その結果、組織全体として第2種過誤のエラーが把握・管理されていても、テスト部門にはそれらのエラーの体系的な記録がまったくない場合があります。
3．戦略的なテストエラー
テスターは、テストに関わらない人がエラーと認識しないような「間違い」に遭遇することもあります。たとえば（英文）
、あるテストスイートは完璧に動作するかもしれませんが、技術的負債が蓄積されることにより、いずれ動作させることが難しくなります。このような脆弱性はエラーですが、少なくとも短期的には、テスト部門の顧客が関心を持つのとは異なるレベルにあります。
このテーマのバリエーションとして、テストで使用するツールが関係するものがあります。よく機能し、技術的負債がほとんどないために機能拡張に迅速に対応できるテストスイートを考えてみてください。しかし、ライセンスが切れているツールや製品の移行先の新しい環境にライセンスが対応していないツールにテストが依存している場合、これは戦略的なエラーとなります。
テスターはこのようなエラーに敏感である必要がありますが、「本物の」エラーとして報告するのではなく、自分たちのやり方を更新および修正するためにこのようなエラーを利用すべきです。
4．運用上のエラー
ファイルシステムが一杯になったとき、DNS がオフラインになったとき、あるいは組織のセキュリティ証明書の有効期限が切れたとき、そのサービスや製品はどうするのでしょうか？
このようなエラー処理を要件として明示的に定めている場合もあります。その場合は当然ながら、テスターはソフトウェアがリソースの枯渇に正しく対応することを検証する必要があります。このような事象には独自の経路があると組織が判断し、少数の顧客が「謎の障害17」(Mysterious failure 17)を見ることは問題ないとする場合もあります。特別なチームが障害17（failure 17）やその他の予想外の問題を処理することになっているからです。時には、組織は正しく設定されたファイアウォール、ライセンスサーバー、および最新のソフトウェアの背後で連携する他のすべての簡単に忘れられる部分への依存を見失うことがあります。
テスターは、これらの障害を理解するための専門的な責任を感じるべきですが、ほとんどすべてのテストチームにとって、運用上のエラーはせいぜい二の次です。ほとんどの場合、「ソフトウェアで診断されていないエラーが発生した場合、エンドユーザーには標準エラー画面Gが表示される」あるいは「… エンドユーザーに表示される内容は予測できない」と報告するだけで十分です。
注意してほしいのですが、ここで使われている意味での「運用上の」エラーは GUIの自動化によって示されることはありません。このようなエラーは、通常のテストでフォーカスを当てるGUI操作ではなく、環境の変化によって発生するものです。
5．ユーザーエラー
最後に、テスターが最も注意を払うべきエラーの 1 つがユーザーエラーです。エンドユーザーは、可能な限り JPEG ではなくPDFをアップロードします。なぜなら、個人設定を更新しようとすると、名前や属性が見えなかったり入力できなかったりすることが頻繁にあるからです。
そのような場合にユーザーに何を表示するかを要件で明示的に指定しているなら、それはとても良いことです。理想的には、プロジェクトの定義段階でQCチームと製品チームが協力して、ユーザーエラーだけでなく、ドキュメント、テスト容易性、および製品の軽視されがちな側面を含む要件を指定することです。しかし実際問題として、ほとんどの場合、製品チームが考慮しなかったユーザーエラーをテスターが発見できるのはリリース間際です。誤って処理された潜在的なユーザーエラーは、特に重要な報告事項です。このような報告をありがたく思う組織はほとんどありませんが、良心的なテスト専門家は、エラーを正しく処理することがエンドユーザーのエクスペリエンスをどれだけ向上させるかを認識しています。ユーザーエラーを記述して追跡する時間を作りましょう。
事前に計画を立てる
テスト作業では、必然的に単なる「本物の」製品エラー以外のものにも遭遇することがあります。5種類すべてのエラーについて、テスターが注意を払い管理する必要があることを、前もって認識しておいてください。意図的に「本物の」エラーだけを報告するように決定することは、偶然エラーが報告されるよりもはるかに健全です。十分に成熟したテストチームは、これらのエラーをすべて明示的にキャプチャし、さまざまな対象者にとって意味のあるカテゴリだけを組織の他の部門に報告します。
作者について：
Cameron Lairdは、受賞歴のあるソフトウェア開発者であり著作者です。業界のサポート団体や標準化団体に参加しており、Python Software Foundation の投票メンバーでもあります。長年テキサス湾岸に居を構え、お気に入りのアプリケーションは農業自動化向けのアプリケーションです。
（この記事は、開発元 Ranorex 社 Blog 「Managing 5 Common Types of Errors in Software Testing」2022年3月1日の翻訳記事です。）
