デバッグにおけるテストで必ず押さえておくべきポイント7選
こんにちは！株式会社コアテックでWEBマーケティングを担当している保志と申します。
SEO施策やサイトのリニューアルを行うにあたって、デバッグという作業は切っても切り離せない存在です。
デバッグにおいて、どのようなポイントでバグが出やすいのか、どこに注目して確認するべきか考えたことはありますか？
今回は、バグが発生しやすい箇所や確認する際に意識していることについて、具体的なエピソードを交えながら詳しくご紹介します。
デバッグに関する悩みを抱えている方にとって、少しでも参考になれば幸いです。
1. 仕様を当たり前と認識しない
簡単そうで一番難しいことを最初に紹介します。
ベテランな人や、サイトに詳しい人ほど難しくなります。
会社に長く勤めていると、サイト全体の仕様がある程度分かるようになりますが、その仕様を当たり前だと思い込み、確認漏れが発生することがあると考えています。
そのため、仕様を確認する際に重要なのは、初心を忘れないことです。
図1のサイトでは、ボタンの右側に内部リンクを2つ追加しています。リンクもボタンもクリックできるのが普通ですが、私は確認の際、一旦その常識を捨てて疑います。
図1の場合、「『Aへ遷移するリンク』をクリックしたらページAに遷移するはずだけど、本当に遷移できる？」という考えが最初に出てきて、さらに「その隣にあるボタンは前からあるけど、今も押せるの？」というように考えが派生していきます。
そこで、ボタンのクリック動作を確認したところ、実際にリンクとしてクリックできる範囲が図2の新しい導線（緑の枠）と重なっており、ボタンの右側が反応しない状態になっていました（赤い斜線部分）。
この場合、導線の幅を文字数分以上に広げる必要はないため、ボタンと重ならないように緑の枠を狭くするなどの調整が必要です。
このバグは、ボタンのさまざまな箇所をクリックすることで発見しました。また、DevToolsを使って各レイアウトの幅を確認するのも有効な方法です。「ボタンは必ず押せる」という前提を持たないことが重要だと思います。
2. 仕様書に記載されていないことを確認する
仕様書に記載されている内容を確認することはもちろん大切です。
しかし、それだけで終わらず、記載されていない仕様も確認することで、バグの発見に繋がると考えています。
「記載されていない仕様ってどういうこと？不備を見つけろってこと？」
いいえ、そうではありません。
これは、仕様の裏側にある事象も確認するという意味です。
例えば、仕様書に「デバイスがSPの場合に追加する」と記載されていれば、スマートフォンで正しく追加されているかを確認するでしょう。
この場合、逆に「デバイスがSPでなければ追加されない」ということも考えられるので、PCなど他のデバイスでも確認が必要です。
次に、URLに設定されたGETパラメータを確認します。
仕様書には1〜5の数字が対象と書かれていたので、それに基づいて確認しました。
しかし、仕様の裏側を考えると「1〜5以外の数字を入力した場合はどうなるか？」も確認すべきです。
例えば6や10を入力した場合、予期しない動作が起こる可能性があるかもしれません。
3. 新しい仕様（メインとなる仕様）と同様に流用した仕様を確認する
新しい仕様については、多くの人が理解していると思います。
しかし、今回お伝えしたいのは、過去に確認した仕様についてです。流用した仕様にもバグが発生する可能性があります。
「以前は問題なかったから」といって確認を省いて良いというわけではありません。
優先順位をつけて確認することは大切ですが、確認自体を省略するべきではないということです。
しっかりと幅広く確認することで、サイトの品質向上に繋がると考えています。
4.確認を先延ばしにすることのリスク
デバッグに時間をかけるのは面倒だと感じるかもしれませんが、「他の人に任せればいい」という考え方は適切ではありません。
確認の期限が迫ってくると、その数分が他の業務にも影響を与える可能性があるため、時間のあるうちに確認を済ませて次の作業に取り組むことが大切です。
たしかに、「特定の手順を踏む」や「テストデータを準備する」などの確認作業は面倒に感じることがありますが、期限が迫ってくると焦ってしまい、冷静な判断ができなくなるかもしれません。
その結果、バグを見落としてしまう可能性があるため、時間を見つけて先に確認するように心がけましょう。
5. デザインやレイアウトの幅を意識する
デザインに対して、文字列を無制限に入れられるわけではありません。
文字数が規定量を超えた場合、どのように表示が変化するかを事前に確認しておくことが重要です。
例えば、テキストが2行になるのか、デザインの内側に隠れて見えなくなるのかなどをチェックしましょう。
また、DevToolsを使用すると、ユーザーには見えない部分に別のデザイン要素が隠れていることもあります。
これらのバグを放置してしまうと、後にデザイン崩れや予期しないバグに繋がる恐れがありますので、十分な確認が必要です。
6. 開閉タイプのデザイン
私の経験では、開閉型のデザインにおいて多くのバグを発見してきました。
開閉型のデザインとは、ハンバーガーメニューやアコーディオン、モーダルなど、クリックすると隠れていたコンテンツが表示され、再度クリックすると元に戻るようなデザインです。
このようなデザインでは、閉じた状態、開いた状態、さらにもう一度閉じた状態でも正しく動作するかを確認することが重要です。
例えば、アコーディオンを開いたときにページ下部のデザインに影響が出ていないか、モーダルが表示された際に他の部分が非活性になっているか、スクロールしても反応しないかなど、想定される動作に差異がないかをしっかり確認することが大切です。
アコーディオンを開いてリンク先を確認して終わりではありません。
次に、閉じた際にコンテンツが元通りになっているか、モーダルを閉じたときに非活性になっていたボタンが再びアクティブになっているか、スクロールが正常に機能しているかを確認することも重要です。
さらに、GTM（Google Tag Manager）で計測を行っている場合、HTMLの構造が変わっている可能性もあるため、イベントが正しく発火されるかも併せて確認しておきましょう。
7. DevToolsでデータを確認
GTMで意図したイベントが発火されない場合、プレビューモードとDevToolsで記載内容を確認します。
よくある原因は以下の通りです：
ダブルクォーテーションの位置が正しくない
不要な空白が入っている
URLの末尾に「/」や「#」が入っていないため完全一致しない
また、サイトに特殊な仕様がある場合は、DevToolsにてデータレイヤーやイベント発火に使用するデータ自体を目視で確認しましょう。
要素タブ(Elements)の検索窓でデータを直接確認するのも有効です（図5）。
まとめ
「デバッグ」とは、単なるエラー修正作業ではなく、ユーザー体験を向上させるための重要なプロセスです。
今回ご紹介したポイントを押さえることで、より効果的にバグを発見し、修正することができるでしょう。
特に、仕様を当たり前と認識せず、仕様書に記載されていない部分や流用された仕様にも注意を払うことが、見落とされがちなバグを発見するために重要です。
また、デザインやレイアウトの確認、DevToolsを使った確認作業も欠かせません。
これらのポイントを意識しながらデバッグに取り組むことで、より高品質なWebサイト改修をリリースできるようになります。
デバッグは根気のいる作業ですが、その努力がユーザーの満足度につながることを忘れずに、日々の仕事に取り組んでいきましょう。
コアテックのマーケティングブログでは、WebマーケティングやSEO、データ分析などのノウハウや社内事例を今後も紹介していく予定です。フォローやスキをいただけると励みになります。
一緒に働く仲間も募集しています！
最後までお読みいただきありがとうございました！