はじめに
あなたはバグ（ソフトウェアの不具合）、特に基本的なバグを見逃したことはありますか？ もしそうであれば、その時、「どうしてこのようなバグを見逃したのだろうか」と自分に聞いてみたことはあるでしょうか？
ソフトウェアテストの実行者であれば、誰でも下記のようなケースを体験したことがあるはずです。
I. テストをしたはずのテストケースにおいてバグが発生する
II. 基本的な（すごく簡単な）テストケースを見逃す
III. 要件を把握できない
ソフトウェア開発ライフサイクルでは、テストは最後の工程となるため、見逃されてしまったすべてのバグはテスト実行者の責任であるという考えが一般的です。このため、バグを見逃すことはテスト実行者として最悪のことだといっても過言ではありません。バグの見逃しというのは実行者の自身の不注意などによるミスで起きるほか、客観的な原因でも発生します。
そこで、この記事ではバグを見逃すことを避けるために注意したいことをご紹介したいと思います。
主観的な原因
ソフトウェアテストはロジックや根拠に基づいていることが望ましいとされています。ただ。残念ながら人間は必ずしも100％ロジックで動くわけではありません。ソフトウェアテストの世界でも、しばしば以下に掲げるようなことが原因となり、ミスが発生します。
１．パラレルトレンド（Parallel trend）
パラレルトレンドとは、同じような条件の場合には同じ結果が出ると信じることです。これは一番よく起こりがちなミスです。例えば、あるテストケースをきちんと実行した後（結果：OK）、別のシナリオを実行する際、先ほどと同じテストケースを見ただけですぐに結果も同じであると判定してしまう傾向が該当します。こうした思いこみは潜在的なバグを見逃してしまう原因となります。
パラレルトレンドを避ける方法としては以下の取り組みが効果的です。
I. 同値分割法と境界値分析を用い、テストケースを作成すること
II. 同値分割法により特別なケースを確定すること
III. 同じシナリオであっても油断しないこと（思い込まない）
２．確証バイアス
確証バイアスとは、仮説や信念を検証する際、それらを支持したり、肯定したりする情報ばかりを集め、反証する情報を無視または集めようとしない傾向のことを指します。例えば、自分がテストを実行する際、ある開発者の技術力が低いと信じ、その開発者が担当した部分のテストにより多くの時間をかけたとします。
その結果、他の開発者が手掛けた部分に対して十分なテストを実行する時間が足りなくなり、バグを見逃してしまうといったようなことが該当します。また、逆にある開発者の技術力が高いことを過度に信用した場合、その開発者が手掛けた部分のテスト実行が不十分になる可能性があり、これも潜在的なバグを見逃してしまうリスクにつながります。
確証バイアスを避ける方法としては以下の取り組みが有効です。
I. テスト実行中は極力思い込みを排除し、常に中立的なスタンスを保つこと
II. 根拠がないことに頼らないこと
III. また、たとえ根拠があっても「例外の可能性があること」を信じること
３．認識不足
少し見ればわかる非常に簡単なバグでさえも特に見逃してしまうことがあります。その主な原因としては以下のようなことが挙げられます。
I. システムのある部分に意識を集中し過ぎた結果、その周囲に注意が向かないこと。
II. あまりにも明らかな現象に対して「バグではない」、「このような簡単なバグはもしかして他の実行者が既に検出済みだろう」と自己判断すること
III. 他のタスク（指摘の修正やバグレポートの作成など）が飛び込みで入り、作業に集中できなくなった結果、バグを見逃すこと
IV. テスト方法と新しい観点を更新しないこと
こうした認識不足を避ける方法としては、以下の点に注意することが大切です。
I. 同時進行で複数のタスクを抱えている場合であっても、どんな小さなことにも油断しないこと
II. 多方面からシステムを検証し、テスト方法を継続的にアップデートすること
４． バグの報告忘れ
例えば、モジュールAをテストしている際、偶然にモジュールBのバグを見つけたというケースを想定してみましょう。この時、その場でメモなどを残さなかった場合、後で報告しようと思ってもうっかり忘れてしまうということが起こり得ます。
また、テストを実行していると、バグを発見したものの、要件が曖昧だったり設計書に書かれていなかったりなどの理由からすぐにバグかどうか判断できないようなケースにも直面します。その時、開発者や上司が忙しく、相談しづらい状況だった場合、「迷惑をかけたくない」という気持ちが優先し、結果的に報告を怠ってしまうこともあるでしょう。
もしくは、「このバグはこのモジュールAに対して優先度が低い」と自己判断し、後で報告しようと思ったものの、実際にはモジュールBに対してクリティカルなバグであることが後になって判明し、問題を大きくしてしまった経験がある人もいるのではないでしょうか。
これらの報告忘れを避ける方法としては、以下の点に気をつけましょう。
I. 少しでもバグの可能性に気がついたのであれば、すぐに報告すること（もちろん根拠やエビデンスを用意した時）
II. 場合により、すぐに報告ができないようであれば、きちんとメモに残すこと
III. 報告は早ければ早いほど良いということを認識した上でテスト実行に当たること
客観的な原因
次にバグの見逃しを招いてしまう客観的な原因についてご紹介します。
１． ミスコミュニケーション
一番多くみられるのが担当者同士のミスコミュニケーションが原因になるケースです。一般的には以下のようなケースが挙げられます。
I. 開発者チームによるバグ修正やコードリファクタリングなどにより、過去にテストが成功した箇所で古いバグまたは新しいバグが発生することがある
II. 開発者が些細な問題だとして特に報告をせずにコードを修正した場合もバグの発生原因となり得る
III. 要件の変更が遅いタイミングで共有された結果、バグではない箇所がバグになることがある
IV. 多数のチームが関わる案件においてチーム間のコミュニケーションが不足した場合もバグの見逃しにつながる
V. 一人で一つのモジュールを担当することにより、他のモジュールのバグを検出できないことがある
こうした問題を避けるためには、以下の取り組みが重要になります。
I. コードを修正した場合は、どんな小さな修正であっても正しく報告すること
II. 新しいコードはシステムにどのような影響を与えるかを分析すること
III. 前回のテスト結果とエビデンスを保存すること
IV. チーム同士でコミュニケーションの機会を増やすこと
V. システム理解度を上げるため、テスト実行者にいろいろなモジュールを体験させること
２． リリースの圧力
顧客はできる限り早くプロジェクトを完了させ、製品を市場にリリースしたいと考えています。リリースのスピードを重視するためにテスト工数を削減するケースも少なくないため、その分の負担の多くをテスト実行チームが負うことも少なくありません。
例えば、顧客が希望するリリース時期を優先するため、テスト実行チームが残業で対応する中、疲労やストレスにより実行者の作業品質が下がってしまうこともあります。また、時間的な制約により今回のリリース対象の一部のテストをスキップした結果、その部分でバグが発生してしまうといったことも起こり得ます。
こうしたことを避けるためには、以下のポイントを押さえて対応することが大事です。
I. できる限りテスト自動化を進めること
II. 正しくリスクを分析すること
結論
ソフトウェア開発ライフサイクルにおいてはバグが発生するのはどうしても避けられないことです。ただ、それを言い訳にして、テスト実行時に不注意などにより毎回バグを見逃してしまうのはソフトウェアテストの専門家としてはあってはならないことです。
このため、より優れたテスト実行者になるためには、過去の失敗や見逃しなどからしっかり学び、自分自身を日々アップデートし続けることが大事です。本記事がテスト実行者の皆さんに少しでも役立つ情報をご提供できたのであれば、筆者としても嬉しい限りです。
私たちSHIFT ASIAはソフトウェアテスト・品質保証のプロフェッショナルとして、今回ご紹介したバグの見逃しを防ぐソリューションをはじめ、さまざまなソフトウェアテスト・品質保証、開発などのソリューションを提供していますので、ご興味があれば以下のソリューション概要をご覧ください。
