テストとチェック

「見たときは大丈夫だったのに、公開したら動かなかった」。そんな事故は、公開前のテストで、かなり減らせます。

テストは「全員で」やる

テストは、エンジニアだけの仕事ではありません。見る観点が違うからです。

役	見ること
エンジニア	動作、表示崩れ、リンク切れ、速度
デザイナー	デザインどおりか、余白や文字の大きさ
ディレクター	要件どおりか、文章の誤字、お客さんの目的に合うか
お客さん	内容の誤り、使ってみた感じ

チェックの観点

表示

• パソコン、スマホ、タブレットで、レイアウトが崩れていない
• 主要なブラウザで、同じように見える
• 画像が切れたり、ぼやけたりしていない

動作

• すべてのリンクが、正しいページに行く
• お問い合わせフォームから送ると、メールが届く
• 必須項目を空にすると、エラーが出る
• メニューの開閉など、動く部分が動く

内容

• 誤字、脱字がない
• 住所、電話番号、営業時間、価格が合っている
• 古い情報（前の店名など）が残っていない

見えない部分

• ページの題（タイトル）と説明が入っている
• 共有したときの画像（OGP）が出る
• アクセス解析などの設定が入っている

この図は、チェックの 4 つの観点をカードにしたものです。

1表示

画面の大きさと、ブラウザで崩れない

2動作

リンク、フォーム、メニューが動く

3内容

誤字、住所、価格が合っている

4見えない部分

タイトル、OGP、解析の設定

見つけた不具合を、わかる形で残す

見つけた人が「なんか変です」と言うだけでは、直せません。次の項目をそろえると、直しやすくなります。

1. どのページか（URL）
2. 何をしたか（手順）
3. 何が起きたか、本来はどうなるべきか
4. 使った機器とブラウザ
5. 画面の写真（あれば）

直せない報告

直せる報告

なんか変です

トップのスマホ表示で、メニューを開くと背景が閉じない（機器とブラウザも）

フォームがだめ

必須項目を空にして送ると、エラーが出ずに送信される

たとえば、こんな画面です。種別が「バグ」の課題に、再現手順をコメントで書いています。

• 左上の種別が「バグ」で、件名が「スマホでメニューが閉じない」です。
• 会話の欄に、「iOS の Safari で起きる」という状況が書かれています。再現手順は本文に書く、と添えています。

「完了」の基準を決めておく

不具合ゼロは目指しても、ゼロの確認は難しいものです。「重大な不具合はゼロ。軽微なものは公開後に直す」と、合意しておくと、テストの終わりが決まります。

この図は、見つけた不具合を、影響の広さと困りの重さで 4 つに分けたものです。右上は、公開前に必ず直します。

困りの重さ →

回避策を伝えて直す

一部の人が、強く困る

公開前に必ず直す

多くの人が、強く困る

記録して様子を見る

影響が小さい

公開後に直す

多くの人が、少し困る

困る人の多さ →

テスト用の環境と、本番を分ける

テストは、本番とは別の、確認用のサイトで行います。お客さんに見せるときも、この確認用のサイトを使います。こうすると、公開前の情報が外に出ることを防げます。確認用のサイトは、検索に載らないようにしておくと安心です。

まとめ

• テストは、役ごとに観点が違う。全員で見る。
• 表示、動作、内容、見えない部分の 4 つの観点で確認する。
• 不具合は、手順と状況を書いて、1 件ずつ記録する。
• 終わりの基準を、先に決める。

akamine でやるなら

不具合は種別を「バグ」にして課題にします。再現手順を本文かコメントに書き、担当と期限をつけます。課題の項目 と 課題テンプレート を使うと、毎回同じ書式で記録できます。

• 上の一覧に、「タスク」「バグ」「要望」「その他」の種別と件数が出ます。
• 下では、種別ごとに、使う項目と必須の項目を切り替えられます。

関連する記事

• コーディングの進め方
• 公開（リリース）の手順
• 品質トラブルの対応