エッジケースのバグは解決すべきか？：エッジケースをテストする重要性

ソフトウェアテストにおけるエッジケースとは、ごく少数のユーザーにしか影響しないケースを指す。だとしても、エッジケースのテストが重要なことは変わらない。本稿では、どのようなときにエッジケースのバグを解決すべきか、それとも解決せずそのままにするのかを確認する。

[Chris Tozzi，TechTarget]

　ソフトウェアのテストプロセスで明らかになる問題の緊急度を判断するのは比較的簡単だ。だが、エッジケースが出現することがある。

　多くのユーザーに影響を及ぼす大きなバグは可能な限り迅速に解決する必要がある。だが、エッジケースの問題に優先順位を付けるのは難しい。エッジケースの問題とは、限られた数のユーザーにしか影響しない問題や、まれな状況でしか起きない問題を指す。エッジケースの問題は、「その問題を解決する価値はあるのか」という難しい疑問を開発者やソフトウェアテスト担当者に突きつける。

　この疑問への普遍的な答えはない。とはいえ、開発者にとっても、テスト担当者にとっても、ユーザーにとっても、等しく結果が最適になる方法でエッジケースに対応するうえでの基本的なガイドラインはある。

ソフトウェアテストにおけるエッジケースとは

　ソフトウェアテストにおけるエッジケースとは、エンドユーザーの大半のUX（ユーザーエクスペリエンス）に深刻な影響が出にくい問題を指す。エッジケースは、ごく少数のユーザーにしか影響を及ぼさず、実環境にはめったに存在しない構成や状況下で発生する。

　例として、Webアプリケーションのテストを考える。このWebアプリケーションでは、任意のOSデバイスで接続するユーザーをサポートする必要がある。テストの結果、このアプリケーションが「FreeBSD」を実行するデバイスで正しく表示されないことが分かった。FreeBSDは、ごく少数のユーザーしか利用していないOSだ。アプリケーションのユーザーコミュニティーの大半をFreeBSDのユーザーが占めているのでなければ、ユーザーコミュニティーの大多数には影響が及ばないため、この問題はエッジケースになる。

ソフトウェアのテストでエッジケースを見つけることが重要な理由

　多くのユーザーに影響を及ぼすバグを見つけることは重要だ。だが、エッジケースを可能な限り多く特定することも重要だ。バグが存在するのであれば、多くのユーザーに影響が及ばないとしても、テスト担当者や開発者はそのバグを認識しておく必要がある。

　現在把握しているバグが多いほど、今後発生するバグの総数を減らすことができる。アプリケーションの特定バージョンのエッジケースを確認せずに放置すると、そのバグが将来のバージョンで大きなバグに発展する可能性がある。特に、開発者がバグを顕在化するようにコードを変更した場合はその可能性が高くなる。

　また、エッジケースの影響を受ける小さなユーザーグループを優先するような決定を上層部が下す可能性もある。そのような場合に備えて、エッジケースを見つけておくことが重要になる。先ほどの例で、FreeBSDのユーザーを重点対象とするマーケティング活動の実施を上層部が決定したとすると、FreeBSDユーザーに影響を及ぼすエッジケースを認識しているかどうかが突如重要になる。この場合、上層部の目標を達成するには、先を見越してバグを解決できる能力が役に立つ。

ソフトウェアのテストでエッジケースに対応する際の課題

　エッジケースの存在を把握することと、そのケースにどのように対応するかは別の問題だ。

　エッジケースのバグについて、開発チームとソフトウェアテストチームが直面する主な課題は、時間とリソースをかけてそのバグを解決する価値があるかどうかを見極めることだ。

　例えば、バグが自社のユーザーの0.01％にしか影響を及ぼさず、そのバグを解決するには開発者の10％が1週間かけて取り組む必要があるとしたら、このバグを解決するのは割に合わないかもしれない。一般的には、開発者の時間と予算を他の深刻なバグの解決に振り分ける方が適切だ。

ソフトウェアテストでエッジケースのバグを解決するかどうかの判断

　エッジケースのバグを解決すべきかどうかを決める厳格なルールはない。エンジニアは、以下の点を考慮してケースバイケースで決定を下さなければならない。

バグの影響を受けるユーザーの割合

　一般的には、影響を受けるユーザーが少ないほどバグを解決する意味が薄れる。

収益への影響度

　ユーザー1人当たりの収益も重要で、バグの影響を受けるユーザーが莫大（ばくだい）な収益をもたらすのであれば、例えユーザー数が少なくても、優先順位を上げる必要があるだろう。

バグ解決に要する想定時間

　簡単に解決できるのであれば、解決する価値がある。

バグの解決による他の目標（アプリケーションの新バージョンのメジャーリリースなど）の遅延

　遅れが出るのであれば、バグをそのまま放置する方が合理的かもしれないが、解決によって他の目標に遅れが出ないのであれば、放置する理由はほとんどない。

ユーザーがバグを回避できる可能性

　バグを回避する方法をユーザーに提示する方が実現可能な場合もある。例えば、ブラウザのバージョンをアップグレードすれば回避できるかもしれない。バグが全く存在しないのが理想的だが、回避策を提示できれば、バグを解決する重要度は低くなる。

シンプルなエッジケースか、それとも「コーナー」ケースか

　コーナーケース（エッジケースの一種）とは、複数の条件が満たされた場合にのみバグがユーザーに影響を及ぼすケースを指す。例えば、あまり一般的ではないOSで、あまり使われないブラウザを実行している場合にのみバグが発生するケースだ。コーナーケースの場合、バグの影響を受ける可能性のあるユーザーの数はエッジケースよりも少なくなる。コーナーケースは複数の要因が複雑に絡み合っており、その要因を1つずつ解決していく必要があるため、解決がより複雑になる。コーナーケースの解決は、1つの根本原因と1つの条件で起きるエッジケースを解決するよりも価値が低くなる可能性がある。

ソフトウェアテストでエッジケースに対処する際のベストプラクティス

　エッジケースに可能な限り効果的に対処するには、以下の方針を検討する。

適切なデータの収集

　エッジケースを効果的に判断するには、影響を及ぼすユーザー数と、収益減につながるケースについてのデータが役に立つ。ユーザー数と収益額のデータは、積極的かつ継続的に収集しない限り、簡単には手に入らない可能性がある。

収益とコストの検討

　エッジケースの重要度は、主に、そのバグが事業の目標達成能力にどの程度の影響を及ぼすかによって決まる。エンジニアは、解決には何行のコードを作成する必要があるかといった技術面でエッジケースを考えるかもしれないが、もっと全体像を考えることが重要だ。例えば、バグを放置するとどの程度の事業収益が失われるかや、製品の新機能の開発者をバグの解決で拘束するコストを考える必要がある。

エッジケースの合計数のカウント

　アプリケーションに内在するエッジケースの合計数と、その合計数が時間の経過とともにどのように変化するかを把握する。そうすれば、さまざまなエンドユーザー層にもたらされる影響の種類に関する洞察が得られる可能性がある。エッジケースは特定のユーザーにしか影響を及ぼさないとしてもその数が多くなれば、多くのユーザーに影響を与える1つのバグと同程度あるいはそれ以上に問題かもしれない。いずれの場合も、多くのユーザーに不適切なUXとなってしまう可能性がある。

エッジケース管理の体系化

　エッジケースはそれぞれ異なるが、エッジケースを評価する標準プロトコルを定めておけば、どのバグを解決し、どのバグを放置するかについて一貫した決定を下せるようになる。