私がwebサイトのテストで気を付けていること:第二回

icach-sato

第2回:「”発見が困難な不具合”という泥沼」

みなさん、こんにちは。
タロスカイの佐藤です。

この度、幸いにも第2回を掲載する機会に恵まれました。
1回きりで打ち切り、なんていうこともある世界ですから、続きを掲載させてもらえる幸運に感謝です。

さて、今回のテーマは、「発見が困難な不具合」ということで、前回のラストで触れた仮タイトルと違うじゃないか、という意見の方もいらっしゃるかもしれませんが、大丈夫です。扱うテーマは一切ぶれておりません。

さて、前置きはこのくらいにして、本題に入りましょう。
「完璧を目指す心意気の限界」、つまり不具合を見逃してしまった場合の理由、ひいては不具合の内訳について。
これには、いくつかのパターンがあります。

そのうちの一つとして、前回では
「仕様をきっちり決めていない部分は正誤が曖昧になるから、できるだけきっちり決めよう」
というお話をさせていただきました。

今回は、それとは別の不具合について解説します。

前回の仮タイトルをご覧になった方は、「なんじゃそりゃ」と疑問符を浮かべたはずです。
テレビと水道、なんの関係もないんですから。
ところが、今回お話しさせていただくのは、そういった「一見関係なさそうな」不具合の話です。

あまり具体的な例を挙げてしまうと機密保持に関わるので、それっぽい話に終始せざるを得ないのが歯がゆいのですが、ここではwebサイトの改修において、「記事本文に用いる見出しの色を黒からピンクに変える」というミッションがあり、それを確認することになったとします。

この時、私(テスト担当者)はいくつかの既存の記事と、いくつかの新しく登録した記事とを確認して、
「見出しの色」がピンク色に変わっている事を確認します。
この段階では「仕様達成」が確認できたことになりますし、テスト担当としては、「確認作業完遂」となります。
しかし、後になってお客様の確認担当者から一本の電話が来ました。

「あのー、記事一覧の記事カテゴリー表示、色が違ってません?」

慌てて確認すると、確かに色が変わっています。本来黒かったはずの記事カテゴリー表示が、ものの見事にピンク色に。

現象を確認し、開発担当者に伝えます。
開発担当者は調査してくれますが、原因がわかるまでの時間は、それはもういたたまれないものです。

なぜ、こんなことになってしまったのでしょう。
調査の末に分かったのは、
「見出しの色で参照するパレットと、カテゴリー表示の色で参照するパレットが同一だった」
ということでした。

このケースで重要になってくるのは、関連不具合の存在と、周辺チェックの存在です。

関連不具合とは、「変更点A」に対して類似項目である「ポイントB」が影響を受け、おかしくなってしまう現象を指します。
ここでは、「記事本文の見出し」を変更したことで、同じ記事内で用いる「作者欄の見出し」も変わってしまう、という場合に「関連不具合が起きた」と言えるでしょう。
ここでのポイントは、「ここを変更したんだから、あそこが影響を受けるかもしれない」と想定しやすいところにあります。
想定しやすいので、開発者は影響が出ないように作りやすいですし、テスト担当者も気を付けてチェックします。

周辺チェックとは、関連チェックをより広範にしたものと言えばわかりやすいでしょう。
「見出しの変更」における「関連不具合への注意」は、同じ「記事」という枠組みの中での配慮ですが、ここでは「サイト全体」を見ます。
明らかに関係がなさそうな「トップページ」「検索結果ページ」、そして「記事一覧ページ」、などなど。
これら全てのページを総ざらいすることで、「よもやそんなところで起こるなんて」という不具合を発見できるようになります。
特に、「関係ないんだから影響を受けているはずがない」という思い込みを持ってしまうと、実際の影響箇所を目の当たりにしても、気付かないものです。

これは、以前流行った「アハ体験動画」に近いものがありますね。
あれは、一定時間の間に、動画のある部分が少しずつ変化していくのですが、見ている人はなかなか気づかない。
しかし、一度答えを知ってしまうと、明らかに変化している事に気づくし、むしろ気になってしまう、というものでした。

もちろん、関連チェックと言っても人力作業ですから、見落とす事はあるでしょうし、再現性があまりにも低い不具合で、とても気付かないこともあるでしょう。
ですが、関連不具合に気を配り、周辺チェックを行うことで、潜在不具合検出確率は大幅に上がるのです。

また、不具合の検出について、もう一つ重要な点があります。それは、場数です。
習うより慣れろ、ではありませんが、不具合の検出や見落としを経験することにより、「こういう場合にはこういう影響が出る(かもしれない)のか」という勘所がすこしづつ養われていきます。
少しでも多くの不具合を見つけ出したり、少しでも強い自信を持って「不具合はありませんでした!」と報告できるようになるためにも、確認作業の場数を踏み、実際の不具合ケースを経験することがとても大切なのです。
(もちろん、不具合ケースは見落としより検出で経験するほうがいいですけどね。)

その他の発見困難な不具合の例としては、
「ページ内の画像を右寄せから中央配置にしたら、ページの下に表示されている横棒が消えた」
「記事一覧にカテゴリー表示を追加したら、ヘッダーに無駄な空白行が追加された」
「記事本文のタイトル脇に表示されているカテゴリー表示の色を変えたら、記事一覧のカテゴリー表示が消えた」
などがあるでしょうか。どれも、関連性を見出す事すら困難な事例です。

ということで、今回は「予想だにしな場所で影響を受けた不具合との付き合い方」について綴ってまいりました。
次回は少し短か目の内容を目標に、「見た目が全てではないけれど……(仮)」の回を予定しています。

それでは、お楽しみに。

そして、よいお年をお迎えください。