📜

明日から使える!偽陽性と本物の陽性を見極める方法【ソフトウェアテスト】

2025/01/21に公開

こんにちは。QAエンジニアをしています、Kikuchiです。
今回は、偽陽性と本物の陽性(不具合)を見極める方法について詳しく解説します。

ソフトウェアテストに精通している方には初歩的な内容かとは思いますが、参考になることがありましたら幸いです。

概要

そもそもソフトウェアテストにおける偽陽性とは、「正常なプログラムを検証した際に、テストが失敗してしまう状態(想定したテスト結果が得られない状態)」 を指します。

偽陽性の例を挙げると...

  • ログインができないと思ったら、アクセス権が付与されていなかった(ACLの制限)
  • 一定時刻になってもメールが送信されないと思ったら、メール送信をONにするチェックボックスにチェックを入れていなかった(前提条件の確認不足)
  • 再テストを行うも失敗。と思ったら、新規作成したアカウントでは問題なかった(古いコードの影響)

などなど。

偽陽性を「陽性(不具合)」と誤って開発チームへ報告しないためにも、偽陽性のパターンを知っていることが重要になります。この記事では、偽陽性の主なパターンや、偽陽性と本物の陽性(不具合)とを見極める方法について解説します。

この記事で伝えたいこと

偽陽性を本物の陽性と誤って報告してしまうデメリットとは?

偽陽性を本物の陽性と報告してしまうデメリット...
それは、テスト担当者と開発チームの間で、本来必要のないやり取りが増えてしまうことです。

内容をイメージしやすくするため、図を書いてみました。
※テスターやQAエンジニアがテストを行い、開発チームがプログラムの記述や修正を行う場合を想定しています。

まず、陽性を報告した場合の流れは以下の通りです。

■陽性を報告した場合

続いて偽陽性を報告した場合です。

■偽陽性を報告した場合

偽陽性のパターンを知らないと、偽陽性が陽性に見えてしまうということが起こります。
テスト担当者は「陽性を検知した!」と思って開発チームへ報告しますが、開発チームが動作検証を行うと陽性と思っていた事象が再現しません。そして、テスト担当者に再検証が依頼されます。

偽陽性の場合はプログラム上に不備はないため、開発チームによる再検証は本来必要ないはずです。しかし、テスト担当者から"陽性"の報告を受けたからには、本物の陽性(不具合)である可能性を検証するため、再現確認を行わなければならなくなります。

加えて、開発チームによるテストで事象が再現しない場合には、テスト担当者との間で以下のようなやり取りが行われることが多くあります。

  • 画面はリロードしたか?
  • 前提条件は設定したか?
  • アカウントやデータを新規作成した場合はどうなるか?

上記のやり取りも、プログラムに不備がない偽陽性の場合は、本来必要ないはずです。しかし、特にリモートワークでは、上記の確認や状況の把握に何往復と費やし、結果的に何十分と時間を取ってしまうことも珍しくない印象です。

偽陽性の主なパターン

ソフトウェアテストで検知する偽陽性にはいくつかのパターンがあるように思います。
ここでは、私自身の経験上 ソフトウェアテストにおいて遭遇率の高いものを記載します。

その1:前提条件の設定を忘れている/設定条件の不備

具体例は

  • 一定時刻になってもメールが送信されないと思ったら、メール送信をONにするチェックボックスにチェックを入れていなかった
  • 時刻表示がずれている不具合かと思ったら、タイムゾーン設定がずれていただけだった

など、適切なテスト結果を得るために必要な設定が抜けていた、または不足していたパターン

自社のサービスの仕様を把握していない 企業に入社したての段階や、ソフトウェアテストに慣れていない初心者が陥りやすいかもしれません。私自身もテスターを始めたての頃に何回か経験しました。

その2:画面更新を行っていない

具体例は

  • メッセージを受信できていないと思ったら、画面を更新していないだけだった
  • 動画のアップロードが終わらない不具合かと思ったら、リロードしたら「完了」と表示された

など、一言で言えば「リロードのし忘れ」。

どのページで表示内容が自動更新されるか、または手動での更新が必要であるかの仕様は企業やサービスによって異なるかと思います。

この偽陽性は、ページのデータが自動で更新されない場合(=ページの表示内容を更新するために手動で画面をリロードする必要がある場合に遭遇しやすいです

その3:コード更新後のデータでテストしていない

代表的な例は

  • 再テストを行うも失敗。と思ったら、新規作成したアカウントでは問題なかった

というもの。

この場合の「再テスト」とは、以下の陽性報告の流れの4にあたります。(参考
この再テストでは、テスト担当者は1で報告した陽性の事象が再現しないことを確認します。

陽性報告の流れ

  1. 陽性を検知
  2. 開発チームに報告
  3. 開発チームが修正(コードが更新される)
  4. テスト担当者に再テストを依頼

少し小難しいですが、既存のデータ(コードが修正される前のデータ)上で再テストを行うと、コードは修正されて問題ないにも関わらず1の陽性の事象が再現してしまう、または想定の仕様通りの動作とならないことがあります

その4:ACLの権限が付与されていない

具体例は

  • ログインができないと思ったら、アクセス権が付与されていなかった
  • 機能が表示されていないと思ったら、利用権限が付与されていなかった

など、機能へのアクセスの許可や制限を行うACLの対象外であるパターン

SaaSサービスでは、契約プラン別に利用できる機能に制限を設けていることが多くあります。また、プランを契約している場合にも、管理者側やユーザー側それぞれに対して機能や表示内容へのアクセス権を細かに設定できる場合があります。

テストを行う際に必要なACLの設定を見逃していると、コードには問題がないもののアクセスや利用が制限されるという事象に遭遇してしまいます

番外編📣 キャッシュの影響

偽陽性となってしまう背景に、ブラウザなどに一時保存されているキャッシュが影響していることがあります。

具体例を挙げると

  • アカウントAでログインしたいのにアカウントBでログインされてしまう(ログインしたいアカウントでログインできない)
  • 他ブラウザでは正常に表示されるページが、特定のブラウザやタブではエラー表示になってしまう

など。

対処法として有効なのはこちら。

  • キャッシュの削除
  • シークレットモードでテスト
  • アカウントを複数作成してテスト環境を分ける

シークレットモードでテストを行うと、すんなり上記の具体例のような動作が解消されることもあります。また、アカウントを複数作成してテストする環境によって使い分けることで、具体例一つ目の「別アカウントでログインされてしまう」動作を避けることができます。

Googleアカウントを複数作成してテスト環境を分ける

Googleアカウントは一人で複数作成することが認められています。
あらかじめ複数作成しておき「本番環境はこのGoogleアカウント、検証環境はこのGoogleアカウントを使用する」などと決めておくのもよいかもしれません。


偽陽性と本物の陽性を見極める具体的な方法

偽陽性と本物の陽性を見極める方法は、不具合かな?と思った時点で開発チームへ報告する前に再検証を行うこと! シンプルですが、これに尽きると思っています。

陽性のお面を被った偽陽性は、以下のパターン別の確認方法を実行することで見極めることができます。再検証を行っても事象が再現する場合は、本物の陽性(不具合)として報告しましょう。

その1:設定条件を確認する!時には仕様を確認する!

設定条件の不備による偽陽性を見分けます👀

大前提としてテストを行う前には、適切なテスト結果を得るために必要な設定が完了している必要があります。その上で不具合を検知した場合に、設定内容に抜けや漏れがなかったかを確認しましょう

「どんな条件/設定で、どのような操作を行ったときに、どんな結果になるのか」
少しでも不明な点がある際は、自社のサービスのヘルプや仕様書などを開いて想定の仕様を確認しましょう(※アクセスが許可されている場合に限ります)。

また、新しい機能の開発を行っている場合など参照できる情報が少ない場合には、デザインの担当者や開発者に直接聞きましょう。(認識のすり合わせはとても大事です)

その2:画面更新を行う

  • 画像や動画、CSVファイルをアップロードする場面
  • メッセージやファイルの送受信など、手動で相互にやり取りする場面

では、画面上のデータが自動で更新されない仕様の場合がありますので、偽陽性かを見極めるには「一度リロードして、更新後の画面を確認する」 ことが有効です。リロードはCtrl + Rでできるのでささっと確認してしまいましょう!

自社サービスの仕様と異なると思った場合には、仕様を確認したうえで不具合として報告するのがスムーズです。

その3:コード更新後はデータを新規作成してテストする

再テストの際には、「コード更新前から存在していたアカウントやデータ上で検証すること」を避けること(=新しくアカウントやデータを作成して検証すること)でテスト結果が偽陽性となることを防ぐことができます

ただ、画面表示そのものが修正されている場合などは、再テストの際にアカウントの新規作成が不要な場合があります。ケースバイケースではありますが、コードの修正がどの部分に入っているのか確認していただくのが良いかと思います。

その4:適切なACLの権限が付与されているかを確認する

適切なテスト結果を得るために必要な権限が設定されているかを確認することで、ACLの設定による偽陽性を見分けます👀

テストに使用するアカウントは、どこからどこまでが許可されている想定なのか、ACLはどの画面から設定できるのかを確認します。

↓ その上で

機能が表示されるのが正しいのか、利用ができるのが正しいのかをテストで確認します。

アカウントの利用制限の仕様をあらかじめ確認しておくことで、ACLの仕様(利用や表示制限)を不具合と取り違えてしまうことを防ぐことができます!

まとめ

この記事では、偽陽性のパターンや、パターン別に偽陽性と陽性を見極める方法について解説しました。

私自身がテスター初心者だった頃に「テスト初心者向けの解説記事があったらいいな」と思っていたので、今回書いてみました。個人的な経験談をもとに書いておりますが、テストやQAに役立つことがありましたら嬉しいです✨

Discussion