サイト側で直す候補
リンク切れ、壊れた画像、共通設定など、制作側で確認・修正しやすいもの。
Web QA / Sample
SAMPLE REPORT
エラー数を並べるのではなく、人が次に見る場所を整理する。
2026年8月24日に金子デザインワークス自身の公開サイトで実行したWeb Production QAを、営業用に抜粋・整理したサンプルです。
当時の検証記録のため、現在は修正済みの項目を含みます。このページは現在のk2de.comの不具合一覧ではありません。
TARGETk2de.com自社公開サイト
PAGES7巡回ページ数
RUN TIME約34秒当時の実行記録
00
SAFE MODE
見るために、勝手な操作をしない。
フォーム送信、任意のボタンクリック、削除操作、決済操作を意図的に行わない範囲から巡回します。まずは公開サイトを壊しにくい確認から始めます。
01
FINDINGS
検出したら、全部を「不具合」にしない。
- サイト共通設定
- 当時、robots.txtとsitemap.xmlの404を検出。サイト側で確認・修正する候補として整理しました。
- 壊れた画像
- 問い合わせ整理パック内で画像3件の参照失敗を検出。ファイル配置・相対パスを確認する候補になりました。
- アクセシビリティ候補
- ヘッダー周辺のコントラスト候補を検出。mix-blend-modeなど表示条件が絡むため、自動判定だけで確定せず人の確認対象にしました。
- 外部通信
- Google Analyticsのcollect通信がヘッドレス環境で中断。サイト本体の障害ではなく、外部サービス／QA環境由来として分離する改善対象にしました。
02
TRIAGE
レポートの目的は、次に見る場所を減らすこと。
人が確認する候補
表示条件、デザイン、文章、案件固有ルールなど、自動判定だけでは決めないもの。
外部・QA環境由来
計測サービスやヘッドレス環境など、サイト本体のFAILとして扱わないもの。
「FAILが多い＝サイトが悪い」とするのではなく、修正候補と確認候補を分けることを重視しています。
03
NEXT
15分デモでは、この流れを実画面で見ます。
- 01CRAWLSafe Modeでサイトを巡回。
- 02FINDルール化できる確認候補を抽出。
- 03TRIAGEサイト側・人の確認・外部由来へ整理。
- 04FIT御社のQA工程のどこに入れられるか確認。