概要
WEB サイトのテストに関するマニュアルです。
何を意識してテストに取り組めばよいのか、何をテストすればよいのか等、 WEBサイトのテストをする上で最低限知っておかなければならないことを網羅的に書いています。
テストの重要性
Webサイト制作におけるテストの重要性を、 「クオリティ」と「スキルアップ」の面から書いています。
制作物のクオリティ担保
皆さんもう重々承知してると思いますが、 テストは制作物のクオリティを担保する上で絶対に欠かせない工程です。
10~20ページくらいのwebサイトであれば、 修正項目は、30~50個くらい出てくるのが通常です。難しいレイアウトやアニメーション等を使っていれば100個くらいは普通に出てきます。
ということは、もし仮にテストの工程を挟まなければ、 30~100個のバグを残したままお客さんに提出することになります。
そのままにしておくか、修正するかでクオリティに大きな違いが出るのは当然です。 お客様の満足度にも大きな違いが出ます。
「エンジニアがバグがない状態で作り上げればテストなんていらなくない?」 って思う人もいるかもしれませんが、ほぼ不可能です。
人間なのでミスは必ずあります。 テストを専門に行う業者がいるくらいですからね。 ただエンジニア自身はバグの数を少しでも減らす努力をしていくべきです。
スキルアップ
僕は今まで(今も)大量のサイトやシステムのテストをしてきましたが、 テストをするとこんないいことがあるよっていうのを書いてます。
細かいところに気付ける能力が身につく
何度もテストをしていると、バグだけではなく改善点等も含めてですが、 1分見ただけで10個くらい修正項目が見つかるようになります。
特にデザイナー・エンジニアはこの能力は本当に重要で、 自分で作ったものを、提出前に一度テスターになった気持ちで眺めると修正すべき点がめっちゃ見つかったりします。
ユーザーの立場になって考える能力が身につく
テストはサイトを使うユーザーになりきって行います。
制作をしていると、どうしても制作者としての立場でものを見てしまい、 ユーザーの立場になって考えるということが難しいです。
ユーザーといっても色々いて、能力の異なる人、年配者や年少者、色盲など視覚障害のある人など、さまざまなタイプのユーザーに注目し、それぞれのコンテキストに合わせて考えなければなりません。(ここはサイトのターゲットによりますが。)
このようなあらゆる視点を持ってテストに取り組むことで、ユーザーの立場になって考える能力が身につきます。
これは仕事をする上で非常に重要な「相手の立場になって考える能力」にもつながってきます。
修正リストは成長の宝庫
テストする側と言うより制作する人側の話ですが、修正リストは制作者にとって成長の宝庫です。
大量の修正リストが上がってきた時に、
「こんなに修正項目出てきた・・修正するの大変だな嫌だな・・」
と考えるか、
「ここに気づけなかったんだな、こういう癖があるな、次から意識して直していこう」
と考えるかで、成長のスピードは段違いです。
また、テストしてくれた人には、 自分が作ったものを時間をかけてチェックして修正点を見つけてくれたことに対する感謝の気持ちを忘れないようにしましょう。
テストする側も、このひとはこういう癖があるなとかわかってくると思うので、 気づいたことがあれば遠慮なく共有していきましょう。 言われる側は1意見としてしっかりと受け止めて次に活かす懐の深さを身に着けましょう。
テストをするときの心構え
実際にテストをする時に意識するべきこころ構えです。
大前提
テストをする際の製作物は、「セルフチェックを徹底した状態」で行います。
明らかにわかるミスはテストやコードレビューの段階では存在しない(または限りなく少ない)状態が望ましいです。
何も書かれていないJSファイルがあったり、明らかに不要なコメントアウトが残っていたりというものは自分で気づける箇所です。
そのためにも、普段から客観的な視点をもち製作物をチェックしましょう。
ユーザーになりきる
Webサイトを見るの使うのは、僕たちではなくユーザーです。 採用サイトであれば求職者が見るし、採用サイトの管理画面であれば、お客さんが使います。
制作者の立場でサイトを見ると、 どうしても妥協がうまれたり、気づくべきところに気づけなかったりします。
自分とは別人格を憑依させて、制作者の目線を捨ててテストをしてみましょう。
1つの観点に着目する
Webサイトにはチェックすべき項目がたくさんあります。
デザイン、コンテンツ、リンクの飛び先、TDK ... 等々 細かいところまで数えたらきりがないです。
テストをする時、どれかの観点に着目してサイトを見てみると結構見つかります。
例えば、「誤字脱字だけ」とか「デザインのズレだけ」とか「お問い合わせフォームの動作だけ」とかです。
これはちゃんと科学的根拠があって、カラーバス効果って言います。 ある特定のものを意識し始めると関連情報が自然と目に留まりやすくなる心理効果のことです。
修正項目がないなんてありえない
当たり前ですが、「修正項目は必ず存在する」という気持ちでテストをしないと、 修正項目は見つかりません。
テストはやればやるほど修正項目が見つかります。 同じサイトを10回テストしても、最後まで修正点は出てくると思います。
少し話がそれますが、ディレクターの人にはこの観点は特に重要だと思います。 「修正項目が有ること」は証明できても、「修正項目がないこと」は証明できません。
お客さんの中には、何回も何回も立て続けに修正を依頼してくる人がいますが、 修正項目は見つけようとすればいくらでも見つかるので、 期待値調整をちゃんとしておかないと制作者を苦しめることになります。
修正内容の書き方
テストで修正項目を見つけたときの書き方を解説しています。
具体的に書く
修正内容はより具体的に書きましょう。
例えばお問い合わせフォームにて、 必須項目を入力しなくても送信できてしまうというバグが見つかってしまったとき。
悪い例🙅♂️ 必須項目を入力しなくても送信できてしまう。
良い例🙆♂️ お問い合わせフォームにて「電話番号」の入力欄に、「必須」の表記があるが、 空欄のまま送信ボタンを押しても、お問い合わせ完了ページに遷移してしまう。
悪い例の方は
- 「必須項目」が具体的にどの項目なのかわからない
- 「送信」がメール送信を表すのか、完了ページへの遷移なのか分からない
一方、良い例の方は
- 「お問合せフォーム」とページを示している
- 具体的にどの項目を入力していないのかがわかる
- 「必須」の表記があるという事実を述べており、「必須項目」と断定していない → 本当は任意項目で「必須」の表記を外すだけで良い可能性があるので、こちらの方が親切。
- 「お問い合わせ完了ページに遷移する」という具体的なアクションを明記している
このような違いがあります。
修正リストへの書き方は、制作者への配慮です。具体的に書きましょう!
スクリーンショットを活用する
修正リストに内容を書く時に、言葉だけではうまく伝わらない場合があります。
そういうときは、スクリーンショットを活用しましょう。
ただ、スクリーンショットのファイルをスプレッドシートに貼ると、 セルの領域を多く使ってしまうのと、シート自体が重くなってしまうので、 スクショをURL化できる、「Gyazo」というサービスを使いましょう。
Gyazoへようこそ : スクリーンショットの瞬間共有 (opens in a new tab)
GyazonはGIFもURL化できてしまうので、実際の動きを共有したい時などはとても便利です。
「バグ」と「期待する動き」を切り分ける
修正内容を書くときは、「何が誤りで何が正しいか」をはっきりと分けて書きましょう。 (バグリストは、列自体が別れています)
バグの内容だけを書いて、どう修正したら良いかを書かなかったり、バグの内容と修正内容が混同して結局何を修正すればよいか分からなかったりする文章があります。
文章だけで伝わるように、
「バグ」と「期待する動き」を分けて書きましょう。
チェックリスト
Webサイトをテストする上で具体的に見るべきポイントをチェックリストとしてまとめています。(この項目はサイトテスト時のチェックリストにも組み込まれています)
デザイン関連
- デザイン通りにコーディングができているか
- ブラウザ/デバイス/osによって崩れるものはないか ブラウザ:chrome, safari, firefox, edge デバイス:iOS, android, タブレット OS:Windows, Mac
テキスト関連
- 誤字脱字はないか
- 表記揺れ/スペルミスがないか
- ダミーテキストはないか
- 改行が変な位置でなされていないか
- タイトル, ディスクリプションが適切に設定されているか(OGも含め)
コーディング関連
- レスポンシブの際崩れる要素はないか
- HTML構造に誤りはないか(おすすめのチェックツールはこちら (opens in a new tab))
- ファビコン、タッチアイコンは設定されているか
- OG画像は設定されているか
- クリックできる要素になにかしらのhoverアクションは付いているか
- ハンバーガーなどのモーダル表示時に、背景スクロールはできないようになっているか
- リンク切れはないか(アクセスできないページはないか)
- 重い画像が読み込まれていないか
- 使用されていないファイルがフォルダ内にないか
フォーム関連
- バリデーションは正しく動作しているか ※必須・任意・メールアドレスの形式・メールアドレス確認等
- サンクスページは存在するか
- メールが送信されるか(迷惑メールフォルダ等に入らないか)※本番サーバーで確認
- メールの送信先、タイトル、本文は適切か
- 自動返信メールは設定されているか
プログラム関連
- 検索エンジンにインデックスされるようになっているか(設定→表示設定 にて「検索エンジンでの表示」のチェックを外す)
- (リニューアル案件の場合) リダイレクトは設定されているか wordpressの「リダイレクション」というプラグインで設定
- (リニューアル案件の場合) 引き継がれていないページ(PDFファイル等も含む)はないか