【QA】不具合を発見した時
ソフトウェアやその機能についてテストを行った場合、何かしらの不具合を発見することがあります。
実施者は発見した不具合が市場への流出するのを防ぐ最初の防衛ラインとなります。
では実際に不具合を発見した場合、実施者はどう不具合報告をすればよいか。
※開発チーム所属するQA担当であることを想定した内容となります。
プロジェクトによって不具合を報告する際のルールは様々なため、この限りではないことを留意してください。
1. 事実を報告
まずは確認した現象についてテストの管理者や開発チームの窓口となる方に報告します。
しかし現象を発見した時点での実施者視点では細かい原因等は分からないことが多い為、以下の要素に基づいて現象発生に至るまでの事実をまとめていきます。
（操作意図）どういうテストを行おうとして、
（事前状態）どういう設定で、
（操作内容）どういう操作をしたら、
（現象発生）どうなった
例えば「画面の明るさ変更を確認するために動画再生中に画質設定を開いたらその直後に設定画面が落ちた」という現象があった場合
（操作意図）画面の明るさ設定値の反映確認をするため、
（事前状態）初期設定をした状態から、
（操作内容）〇〇アプリで動画を再生し、〇〇キーで画質設定を開いたところ
（現象発生）その直後に画質設定画面が落ちました
という内容で報告することになります。
ここでより意識したいのが「現象発生によって何が困るのか」を明確にしておくことです。
現象内容によっては文言だけ聞いてもそれによる不都合がイメージしにくい場合がある為、具体的な不利益を伝えることで報告後のやり取りがスムーズになります。
上記で言えば「画質設定画面が落ちるから何が困るか？」という部分。
基本的には「画質設定画面が落ちるので画質設定関連のテストが行えない」というのが一番分かりやすい影響になるかと思います。
2. 原因の特定
ほとんどの不具合現象には原因となる状態があり、状態を再現すれば現象を再現することも可能です。
では具体的に原因を特定するにはどうすればよいか。
まずは原因となりうる場所の切り分けを行っていく必要があります。
1.設定範囲の切り分け
例えばシステムのあらゆる設定はテスト実施を進めていく過程で多くの変更を経ているはずです。"テストケースとは関係のない設定が原因かどうか"を切り分けるために一度全ての設定を初期化してから再現確認するのがよいでしょう。
これで再現すれば原因はテストケースの範囲内、再現しなければテストケースの範囲外に絞れます。
そこから更に範囲を切り分け、絞り込みを進めることで現象の再現が可能な最小設定を導きだすのが目標となります。
ただしここで「現在の値が初期値と同じ」は初期状態ではないことに注意してください。
初期値から別の値に変更しそこから初期値と同じ値に戻した場合も「値が変更された状態」です。
システムやプロジェクトの都合にもよりますが必ず初期化操作を行うようにしてください。
2.導線の切り分け
テストケースの手順を実行している最中に現象を発見した場合、再現手順は必ずしもテストケースの手順そのままとは限りません。例えば初期化した状態から現象発生時の直前に行った操作を実行するなど、現象の再現が可能な最小手順を導き出すよう絞り込んでいきます。
3.機器接続の切り分け
テスト対象のシステムが外部からの接続機器を認識する場合、それらが不具合を引き起こす場合があります。プレーヤーやLANケーブルなど、影響範囲によっては設定値と複合的に作用している場合もある為、いくつかのパターンで検証しなければならない場合もあります。
不具合現象について的確な調査を行うにはシステムに対する高い理解度が求められます。
報告の時点で上記のような切り分けや再現率等の情報が揃っているのは確かに望ましいのですが、その段階での網羅性を意識しすぎると周知の遅れやテストスケジュールの圧迫に繋がりやすいです。
そもそも開発側では既知の現象であるため概ね原因が特定できているなどの場合、必要な検証はより絞られることになりますし、前提となる設定次第では仕様だと判明することもあります。
現象が起きた時点で報告し、その後改めて調査工数をスケジュールに組み込むのがプロジェクトにおいても望ましいでしょう。
3. 不具合を発見するために
当然ながら不具合を発見するためには動作結果が不具合だと認識できていなければいけません。
その為にはどのようなことを意識するべきか。
1.違和感を見逃さない
例えば一見意味が通っているように読めるエラーメッセージ、一瞬挙動が怪しかったが問題なく画面が遷移したなど、違和感はあるがなんとなく期待結果は得られているように感じる動きと言うのはテストを実施している中では珍しくありません。
しかし実施者目線では些細に感じても、開発者目線では重大なリスクに見えるかもしれません。
そういった違和感を見逃さずに報告していくには、自分が確認した動作結果が間違いなく期待結果と一致しているか常に疑っていく必要があります。
ここで重要なのは「不具合を見逃さない」ではなく「違和感を見逃さない」です。
結果として問題がなかったとしてもそれはシステムを理解する上で重要な情報となります。
「今のは大丈夫だろう」という自己判断で片付けず、必ず報告して確実なテスト結果を得るよう心がけてください。
特にシステムへの仕様理解が浅い段階でテストした時に気に留めなかった動作結果が、理解が進むにつれて再度実施した際に違和感のある動作をしていることに気付く事があります。
その際に「過去に通していたから」とそのまま見送らず、報告に挙げることを躊躇ってはいけません。
プロジェクトにおいて最も不利益なのは不具合が放置されることで、例えタイムラグが生じても不具合が発見されるということはプロジェクトの前進に繋がります。
また、仕様理解が浅い段階で見逃がしていた不具合はテストケースの書き方が不十分であるという見方もできます。
「なぜ見逃していたのか」という原因を明確にすることでシステム評価の精度向上に繋げていきましょう。
2.仕様を理解する
基本的にテストはテストケースの内容に沿い、期待結果を確認していければ問題はありません。
しかし実施者がシステムに対してより理解していれば、設計段階では見逃していたバグの検出ルートを見つけられる可能性があります。
設計者の想定よりもより負荷のかかる設定の複合、処理中の特定のタイミングを狙った操作等、扱っているシステムや機器がどういう動きをするのかをよく理解することで、より不具合を起こすリスクの高いシチュエーションに気付きやすくなります。
ただしそこまでの仕様理解を身に付けるには相応の経験が必要になり、またそこを意識しすぎるとテスト工数を不用意に膨らませてしまう恐れもあります。
あくまで決められたテスト計画の達成を第一とし、それ以外の検証行為はテストスケジュールに合わせて行う程度に留めましょう。
4. まとめ
不具合発見時の報告ルールは現場によって様々ですが、開発環境においてはフットワークの早さが求められます。
より深掘りした検証情報も重要ですが、まずは不具合の存在を共有することが最優先となります。
不具合の迅速な解決のために迅速な事実報告に努めていきましょう。