品質管理・テスト設計

品質管理は「最後の工程」ではない

品質管理という言葉から、公開直前のチェック作業を想像されることがあります。
FHWでは、品質管理を次のように捉えています。

• 設計時に判断基準を揃える
• 実装時に前提を崩さない
• 公開前に状態を確認する

つまり、品質は工程を通じて管理するものであり、最後にまとめて作り込むものではありません。

FHWにおける品質基準

FHWの品質基準には、大きく分けて二つの層があります。

社内で共有されている基準

• HTML構造・実装の考え方
• 表示・動作の最低要件
• パフォーマンスや安全性に対する感覚

これらは、日々の制作の中で暗黙的に共有されている基準です。

プロジェクトごとに明文化する基準

一方で、

• 対象デバイス
• 想定ユーザー
• 表示・挙動の許容範囲

などは、プロジェクトごとに明文化して共有します。
これにより、判断のブレや認識のズレを防ぎます。

表示・動作確認の考え方

FHWでは、表示・動作確認を網羅チェックとしては行いません。
すべての端末・ブラウザを対象にするのではなく、モダンブラウザを中心として、

• 利用頻度
• 影響度
• 重要度

を考慮して、確認の優先順位を決めます。
重要な体験に影響する部分を重点的に確認することで、現実的な品質担保を行います。

自動テストとの向き合い方

E2Eテストや自動テストは、常に必須と考えているわけではありません。

• 規模が小さい案件
• 変更頻度が低いサイト

では、手動確認の方が適している場合もあります。
一方で、

• 繰り返し確認が必要な箇所
• 人為ミスが起きやすい部分

については、自動テストを選択肢として持っている状態です。
重要なのは、テスト手法そのものより、どう品質を担保するかです。

公開前チェックの位置づけ

公開前チェックは、バグを探し回る工程ではありません。
FHWでは、

• 設計時に想定した状態になっているか
• 実装の前提が崩れていないか
• 公開して問題ない状態か

を確認します。
これは、最終確認であって、やり直しの工程ではないという位置づけです。

属人化させない品質担保

品質を個人の感覚に委ねると、担当者が変わった途端に品質が不安定になります。
FHWでは、属人化を防ぐために、

• チェック観点を共有する
• 判断理由を記録として残す
• 再現できる確認方法を取る

といった考え方を重視しています。
これにより、誰が担当しても同じ判断ができる状態をつくります。

品質管理と他工程との関係

品質管理・テスト設計は、単独で完結するものではありません。

• 考えるフェーズでの判断
• つくるフェーズでの積み重ね
• 育てるフェーズでの状態把握

これらすべてと連動して、品質は保たれます。