🗂️ Design Materials ＃デザイン資料 – ＃エッジケースとは？バグの見つけ方とチェックリスト

1. エッジ・ケースとは？

⚠️ エッジ・ケースは、ソフトウェアのQAテストでよく聞くトピックです。エッジ・ケースの定義はとても簡単です。ソフトウェア・テストでは、エッジ・ケースは、ユーザーが遭遇する可能性のあるまれなバグのことを指します。

代表的なバグ

*クラッシュ：最も一般的なエッジケースの1つは、アプリがクラッシュしてしまう場合です。 多くの場合、デベロッパーはコードを見て原因を特定することができます。 ただし、テスターとして、クラッシュを簡単に再現できない場合があります。 テスターはこの動作をスクリーンレコーディングなどして表現します。

2. エッジケースを見つける方法

場合によっては、試行せずにエッジ・ケースに遭遇することがあります。 テスターたちは実際のユーザーが使用するよりもはるかに多くのソフトウェアを使用していることになります。 したがって、問題が発生する可能性が増えます。また、ソフトウェアのすべてのセクションと機能をチェックすることを意味します。 これにより、頻繁に使用した結果として発生する可能性のある特定のバグを見つける可能性が高くなります。

また、テンプレ・テストケースを使用すると、エッジケースを簡単に見つけることができます。QAテストケースのガイドがあるので詳細を確認できます。 （英語版のQAテストケースのガイド）

3. エッジケースを修正する必要性

たとえば、1％の確率で発生するバグは、非常にまれに聞こえるかもしれません。しかし、ユーザビリティに深刻な影響を及ぼす場合を考えてみることが大切です。例えば、プラットフォームに50万人のユーザーがいる場合、ユーザーがショッピングカートからチェックアウトできないバグは、収益に大きな打撃を与える可能性があります。

一部のチームは、フィージビリティを考え、バグがエッジケースであるということは、修正する必要がないことと考えています。

💡フィージビリティとは、「実現性」「実現可用性」としてビジネス用語として使われています。一般的には、事業化の可能性、採算性などを調査することを指します。

しかし、これが常に最良の見通しであるとは限りません。 何かが多くのユーザーに影響を与えない、または非常に頻繁に発生するからといって、それが問題を引き起こさないということはありません。特にそれが簡単な修正である場合は修正する価値があります。 これにより、ソフトウェアが改善されるだけでなく、顧客から信頼性を得ることも可能になります。

今回はエッジ・ケースのチェックリストをご紹介します。

4. エッジ・ケースのチェックリスト

1.読み込みの時間が長い
例えば、ユーザーがボタンを押した時に、次のページが5秒以上現れない場合はどうでしょうか？
ユーザーは少しイラつき、プロセスがまだ進行中のときにページを更新、または閉じてしまうかもしれません。ユーザーのアクションが完了する前に、ユーザーのアクションが進行中であることをユーザーに警告する必要があります。
改善例
＊読み込み中のアイコンを表示する、また処理中であることを示すメッセージを画面に表示する
＊プロセス速度を速くする

2. 空っぽ状態を表すデザイン
例えば、ユーザーがアカウントにお気に入り、保存をしていない場合に、何も表示されていない場合は何も役立ちません。またバグのように感じ取られる場合もあります。このエッジ・ケースは、通常、ユーザーが最初に見たときの初期状態であるため見逃すことはできません。
改善例
＊空のリストのメッセージとイラストを表示
＊ユーザーにアイテム追加を促すメッセージとリンクを追加
空の状態のUIデザインは他の場面でも再利用可能な構造でデザインすることをお勧めします。

3.システム・エラーに対処

エラーが発生する場合は2つあります。ユーザーが入力したデータが間違っているか、システムエラーが発生した場合です。

ユーザー入力エラーの場合
＊要件が満たされるまでリンクを無効にする
＊検証確認し、入力の何が問題になっているのかをテキストで表示する
システムエラーの場合：
＊システムに問題であり、ユーザーの問題ではないことを明確にして、ユーザーフレンドリーな言語を使用します

4.ゼロの結果
検索機能があり、結果がの場合はどうなります

ユーザーは、結果がないことを示すメッセージが表示されることを期待しているため、別のキーまたはフィルターを使用して再度検索できます。

繰り返しになりますが、ユーザーが何回も検索を試みて、何も表示されないことが続くと、プロダクトの信頼性が失われる可能性があるので、このエッジケースを事前に回避することをお勧めします。

＊入力の例を提案を表示
＊スペルチェックと検証をする
＊ゼロの結果が見つかったことを表示、同ページに代案リンクを表示する

5. 404エラーページ
404（not found）とは、存在しないページにアクセスしたときにサーバーから返されるHTTPレスポンスコードのことです。

例えば…
＊ページ自体が削除されている
＊サイト側のリンク設定ミス
＊URLを間違えた

こんなときに表示されるページで、エラーページの中では比較的目にする機会が多いページかと思います。
エラーページには他にも
403 Forbidden: 禁止されている/アクセスする権限がない
500 Internal Server Error: サーバ内部エラー

本来は表示されることがあってはならないエラーページ。ユーザーが目にすることがないのがいちばんですが、万が一に備えて最低限ヘッダーとフッターは他ページと揃えておくこと、これだけで印象はずいぶん違ってくるかと思います。

6.テキストが長すぎる
これは、誰もがバグ修正を忘れて泣き叫ぶケースです。深刻なバグではありませんが、ユーザーにとって最も目立ちやすく、UIが壊れることがよくあります。

＊テキストにはデータとして保存する制限が必要です
＊ユーザーがフロントエンドに保存しようとするとテキストに制限があり、UIは検証を表示する必要があります
フロントエンドに省略記号を表示するテキストが長すぎる場合
＊デザインを複数行にする

バグが機能に深刻な影響を与えない場合でも、ユーザーエクスペリエンスがスムーズでない場合は、ユーザーがプロダクトを放棄する可能性を増やしてしまいます。バグに遭遇した場合だけでなく、それ以上の影響を与えることを覚えておくことも有益です。

今回はエッジケースを修正する必要性、またチェックリストを学習しました。

私も、色々勉強中なので、皆さまの、ご意見・ご感想をお聞かせください。お読み頂きまして、ありがとうございました。

メルボルンを拠点にビジュアル・デザイナー、UXスペシャリストとして働いています。 主にデジタル・プロダクトの制作に携わっています。